resolve/resolveRepresentation

[volodymyr-basiuk]

No description provided.

[Copilot]

Pull request overview

Updates DID resolution responses to stop populating didResolutionMetadata.contentType, aligning behavior with the PR’s goal of “do not return content type on resolve”.

Changes:

• Removed “explicit accept” detection logic and stopped setting DidResolutionMetadata.ContentType.
• Defaulted */* responses to application/did-resolution+json.
• Simplified writeDIDResolution by removing the explicitAccept parameter.

Comments suppressed due to low confidence (1)

pkg/app/handler.go:58

• The 406 response body is JSON-encoded DID Resolution, but the header is set to application/did-resolution (no +json). Since this handler now defaults */* to application/did-resolution+json, these error responses should likely use the same JSON media type for consistency and correct client parsing (e.g., switch to acceptDIDResolutionJSON here).

	accept := pickAccept(r)
	if accept == "" {
		w.Header().Set("Content-Type", string(acceptDIDResolution))
		w.WriteHeader(http.StatusNotAcceptable)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Inconsistent Content-Type handling: When resolveRepresentation is called with acceptDIDJSON or acceptDIDLDJSON, the DidResolutionMetadata.ContentType is set to the requested accept type (e.g., "application/did+json"), but the HTTP response Content-Type header is always set to "application/did-resolution" (line 319). This creates a mismatch between what the client requested/expects and what the HTTP layer reports. Consider setting the HTTP Content-Type header to match the contentType in the metadata, or reconsider whether the HTTP header should always be "application/did-resolution" for representation responses.

Suggested change

	w.Header().Set("Content-Type", string(acceptDIDResolution))
	w.Header().Set("Content-Type", string(accept))

[volodymyr-basiuk]

no, we do return application/did-resolution, and exact type application/did+json is inside DidResolutionMetadata.ContentType

[Copilot]

Potential breaking change: Adding omitempty to the DidDocument field means it will be completely omitted from the JSON response when nil, rather than being present with a null value. This is a breaking change that could affect API consumers who rely on the field always being present in the response structure. According to the W3C DID Core specification comment at line 49-50, didDocument "should exist in responses" (though it can be empty for error cases). Consider whether this change aligns with the specification requirements and if it might break existing clients.

Suggested change

	DidDocument *verifiable.DIDDocument `json:"didDocument,omitempty"`
	DidDocument *verifiable.DIDDocument `json:"didDocument"`

[volodymyr-basiuk]

it will be empty only if specified in request with application/did+json or application/did+ld+json accept header, then client expect didDocumentStream