S3: Plus sign is interpreted as space in the path part of URLs

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

Amazon has a difficult time with the HTTP standard sometimes. Last time I had to touch an AWS project we discovered a bug[1] in the C++ code backing a Java library (sic).<p>They had implemented their own HTTP client, but forgot to add the &quot;Host&quot; header to requests which is required by HTTP 1.1.<p>Interestingly this client sent requests only to their own services, which means that they either released that without testing it or the backend once accepted faulty requests.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;awslabs&#x2F;amazon-kinesis-producer&#x2F;issues&#x2F;61" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;awslabs&#x2F;amazon-kinesis-producer&#x2F;issues&#x2F;61</a>

Does anyone know if this behavior persists when the bucket is served as a website?

Anyone that&#x27;s dealt with S3 in any capacity should be aware of this, it&#x27;s literally one of the first encoding problems to come up when dealing with signing requests.<p>@dang can you please add (2010) to the title?

Funnily enough, &quot;URLs and plus signs&quot; is still my most up voted question on stack overflow ( <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1005676&#x2F;urls-and-plus-signs" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1005676&#x2F;urls-and-plus-si...</a> ) -- same a+b example too. 7 years later, it seems even the big names have issue with this.

This burned me and because of it I can&#x27;t host a specific static site on S3 because it requires plus signs. Can&#x27;t change the files being uploaded due to the system generating them... tried to rig up some sort of Akamai rewrite rule to change it at the CDN level but couldn&#x27;t get it to work.

(Update - the original title mentioned AWS has been breaking standards since 2010. The new title is fine. Thanks for updating it.)<p>Little bit of hyperbole in the title imo. S3 has generally been very good at embracing the fundamental principles of HTTP and REST, leaving aside corner cases like this.

I change the &quot;+&quot; into the escaped code :-) It helped

&amp;tldr; A legacy behavior is to treat + as a space. When you&#x27;ve been around you need to keep backwards compatibility.<p>URLs and URIs have separate standards from HTTP and they have changed over time (been replaced by newer ones).<p>Many years ago it was common to encode a space as a + sign. For example, the PHP function urlencode[1] does the same thing with a + sign. If you&#x27;re a PHP user, don&#x27;t use this function unless you know you need to. There are better functions now.<p>[1] <a href="http:&#x2F;&#x2F;php.net&#x2F;manual&#x2F;en&#x2F;function.urlencode.php" rel="nofollow">http:&#x2F;&#x2F;php.net&#x2F;manual&#x2F;en&#x2F;function.urlencode.php</a>

It&#x27;s reasonable they don&#x27;t want to fix it because it will break existing URLs. Welcome to the ugly world of back compatibility.

Should this really be considered to be a spec violation? It&#x27;s a restriction, sure, but S3 is to be considered a specific application with specific constraints.

In response to the reported RFC violation, elving@AWS writes: &quot;I agree that&#x27;s unconventional and unfortunate.&quot; My corporate bullshit detector is off the scale.<p>In earlier times, we would have both the ability and the balls to treat that unwillingness to uphold the rules we all set out with as damage to the Internet, and route around it. But sadly, AWS has become too big to fail, so the engineers introduce special cases into their products and deploy them.