Fix for files and directories with + as a character in the file name b0rking Rack::Directory #265
…/file name.file from the POV of the web server, which is a Bad Thing.
On Tue, Nov 15, 2011 at 11:38 PM, Joshua Peek
I am aware of that. '+' in a filename does not mean a space, however,
On Nov 16, 2011 8:53 AM, "Rich Meyers" <
Then that whoever is Rack::Directory.
If you want a demo, configure a racked webserver to serve an Ubuntu install
A but more background:
I encountered this bug when trying to use Rainbows to serve up an Ubuntu install tree for net installs. Out of all the web servers I tried, only Rainbows failed to act as a backing webserver when using Rack::Directory to serve up the directory tree -- the install failed the first time it tried to serve a filename with a + in the name.
wget will print a directory index for the first pull, and get 404 errors for the second and third. The Rainbows output will show:
127.0.0.1 - - [19/Nov/2011 09:27:45] "GET / HTTP/1.0" 200 - 0.0153
With the changes in this patch, I get:
127.0.0.1 - - [19/Nov/2011 09:39:55] "GET / HTTP/1.0" 200 - 0.0046
Webrick, nginx, thttpd, and apache all do the expected thing. The issue is not whether the client is failing to properly encode requests to the server (unless wget has managed to get it wrong for all these years). The issue is that Rack appears to be doing the Wrong Thing when decoding the requests and matching them against the files I am asking it to serve.
I am patching rack to correct the output of the Directory Index from Rack::Directory.
I will not support not escaping file names at this time. Escaping is expected and required by rack in order to conform to RFC.
If you believe this is in error, feel free to continue the discussion. At this time, supporting reading files from uris that are not correctly escaped will not be supported.
Thank you for your bug report, even though we may not agree on the solution, I have fixed the bug that is apparent in Rack::Directory.
Of course file names should be escaped. The bug is that valid URI paths are incorrectly unescaped.
From RFC 3986:
This is still a bug. Worse, it's been worked around in Rails in an additionally buggy way, to great confusion and gnashing of teeth: rails/rails#11816 (comment)
The proposed fix here (removing unescaping) is wrong. The right fix is to unescape as pchar instead of the blanket