[ryanbrunner]

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.

[asdfaoeu]

Sure but /%2B should resolve to the same thing as /+

[ryanbrunner]

Ah, fair enough, that's a good point.

[jamix]

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.

[zAy0LfpBZLC8mAC]

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

[jchw]

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.