solid
Server should partially encode Slug header values
Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].
— 5.1 Resource Type Heuristics
The value supplied by a caller in the Slug header ends up an being an IRI path segment.
Because of this, implementations must deal with slug characters that would be invalid in a segment.
At least one implementation currently strips invalid characters.
I propose mandating that implementations percent encode offending characters if they honour the slug:
POST /container/
Slug: a/b
HTTP 201
Location: /container/a%2Fb
We should suggest that servers do not encode any other character but the ones illegal in path segments:
POST /container/
Slug: fancy-slug!
HTTP 201
Location: /container/fancy-slug!
The offending class of characters that should be encoded is anything outside of pchar (RFC 3986).
I think %2 is still dangerous if there are other bugs in the server or conversions happening in a reverse proxy. Slugs with slashes, encoded or not, should likely be rejected in any case, to avoid that they turn into containers.
Yes, the topic of more sophisticated use of Slug has been discussed at some length, mainly in https://github.com/solid/specification/issues/128#issuecomment-573033297 and onwards. We decided not to tackle it yet.
However, the slugtext is just a hint to the server of what the server might want to do, and some of these details may also be left as implementation detail. Personally, I could see us assign meaning to slashes to create containers :-) Others disagree.
