POST/PUT requests in use cases shouldn't use relative URLs to reference the context

[lanthaler]

For example use case 5.

The problem is that a POST/PUT don't have a base URL and so the relative URL can't be resolved. Using the target of the POST/PUT as base is not the right thing to do.

[tpluscode]

Did we not just assume some default base to be assumed for all use cases?

[asbjornu]

I don't understand the premise. How does any HTTP method have a better grasp of a base URL than others? Don't all HTTP methods have the same context? An initial request needs the full authority, protocol and so on, but from there, won't the base URL just be the URL of the previous request?

[lanthaler]

We are talking about request base URL vs. response base URL here. AFAIK, the request doesn't have an implicit base URL. Do you have a pointer to a spec somewhere that says otherwise?

[asbjornu]

Section 5 of RFC 3986 talks about how to resolve a URI and section 5.1 in particular; how to establish a Base URI.

[elf-pavlik]

https://tools.ietf.org/html/rfc3986#section-5.1.4

A sender of a representation containing relative references is responsible for ensuring that a base URI for those references can be established. Aside from fragment-only references, relative references can only be used reliably in situations where the base URI is well defined.

I think we should update snippets of POST/PUT payloads to use full URLs for @context

[asbjornu]

I don't mind using full URLs, but I would say it is pretty obvious that section 5.1.3 - Base URI from the Retrieval URI applies here.

[elf-pavlik]

I wouldn't interpret it this way, 5.1.3 seems to describe a case where client retrieves representation and based on the URI it requested (including following redirects) establishes the base URI.

In our case we have a client sending a representation and server receiving it has to establish base URI for relative references. In this case according to 5.1.4 the sender (client) needs to ensure that server can establish such base URI.

I can think of a case where server redirects some traffic to a different sub(domain), in that case relative reference in representation sent by the client might require base-URI of the initial request and not the one after redirect. In that case server assuming URI of the request it receives as base-URI for the representation would create a different URI that one intended by the client.

[asbjornu]

Aha, so the base URI needs to be established from the request. That's indeed different and a nuance I hadn't understood until now. Yes, for requests, the URI needs to be absolute. Is it a problem to mandate that?

[lanthaler]

No, we just need to do it and update the use case docs to do so.