4 ms·

I don't necessarily think this is even breaking the HTTP standard. While '+' should not be interpreted as spaces as part of a URL while it's being treated as a

I don't necessarily think this is even breaking the HTTP standard. While '+' should not be interpreted as spaces as part of a URL while it's being treated as a URL, the HTTP spec doesn't specify / care what file that may map to on a server. Edit: As mentioned below, this isn't correct since URLs should be able to be escaped and return the same resource, and an escaped + differs from an unescaped + on S3.

jamix 9y ago
Exactly! The OP's point is summarized in this sentence: > My point is that the spec requires + to be escaped only inside the querystring. So what? What the standard mandates for query strings is irrelevant here. It's up to the server how to interpret and map the URLs. "Unconventional and unfortunate" - yes, but breaking the HTTP spec? No.
- jchw 9y ago
  It breaks the HTTP spec because it internally is decoding the URL wrong. This is important because things that speak HTTP are free to choose to percent encode, or not, the plus sign in a path, and the canonical URL should not differ. If it mapped even an escaped plus to a space, it'd be consistent, though still questionable, behavior.
- zAy0LfpBZLC8mAC 9y ago
  Please read the actual spec before telling poeple whether something is conforming to it or not. Just making stuff up is exactly how this mess is created. The relevant section in this case: https://tools.ietf.org/html/rfc3986#section-6.2.2.2 https://tools.ietf.org/html/rfc3986#section-6.2.2.2
- deleted 9y ago
  [deleted]
asdfaoeu 9y ago
Sure but /%2B should resolve to the same thing as /+
- ryanbrunner 9y ago
  Ah, fair enough, that's a good point.