Partial URLs in 201 Created Location header?

[FlorianWendelborn]

In 7.4.1 you encourage the use of the Location header. Is there any policy/rule regarding using a full URL versus only the URL path?

I also suggest to make the guideline more verbose regarding my question, as it's often slightly inconvenient to respond with the full URL, and I can imagine a lot of people would prefer to have a shorter alternative.

[johngossman]

Generally we always want to use the full URL so the client doesn't have to track state.

[FlorianWendelborn]

@johngossman I'm quite sure that the client needs to know which server he's trying to connect to, which would also be enough state to turn this back into the full URL. Depending on the framework used, it may even be easier to request a path on a server, instead of changing both every time.

But in general, I have to agree that not being forced to track state in the client is a good thing though.

[garethj-msft]

As John says, we're tending to standardize on absolute URLs, with the expectation that they require zero client manipulation. It is interesting feedback that you feel the path only may be easier with some frameworks.

[darrelmiller]

@johngossman @garethj-msft Arguably the client doesn't need to track any state to resolve a relative reference in a Location header RFC 7231 7.1.2 as a relative reference in a Location header is supposed to be relative to the request URL. In most client situations the request URL is available when processing the response.

It is some work on the part of the client however it should be something as straightforward as,

  var resolvedLocationUrl = new Uri(request.RequestUri, response.Headers.Location.OriginalString);

and this will work for both relative and absolute Location URLs, so the client doesn't even need to check.