clarification: "Location" header bevahior?

[rchincha]

As per spec, "Location" header is typically of the form:
Location: /v2//blobs/uploads/<session_id>

Also,

Though the URI format (/v2/<name>/blobs/uploads/<session_id>) for the Location header is specified, clients SHOULD treat it as an opaque url and SHOULD never try to assemble it.

However, docker distribution appears to return a fully qualified "Location" header value of the form:
https://<server_ip>:<server_port>/v2//blobs/uploads/<session_id>

This behavior needs further clarification. What should be a compliant client's expectation from the server? In one case, it needs to prepend the Location header with the (scheme,address,port) and in the other, not.

[jonjohnsonjr]

I think we can just defer to RFC 7231:

The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).

[rchincha]

So this would mean the client needs to distinguish between the two Location formats, which is fine. Should this be called out in the dist-spec?

[jzelinskie]

Absolutely. We should add a link to the RFC in all the tables that document the headers for endpoints -- some of them are even empty for Location.

[jdolitsky]

Resolved by #206