* [ANN] unicorn 0.95.2 - small HTTP parser fixes
@ 2009-12-07 10:01 Eric Wong
0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2009-12-07 10:01 UTC (permalink / raw)
To: firstname.lastname@example.org (ruby-talk ML) ,mongrel-unicorn
Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels. Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.
* email: email@example.com
* finger: firstname.lastname@example.org
Small fixes to our HTTP parser to allows semicolons in PATH_INFO
as allowed by RFC 2396, section 3.3. This is low impact for
existing apps as semicolons are rarely seen in URIs. Our HTTP
parser runs properly under Rubinius 0.13.0 and 1.0.0-rc1 again
(though not yet the rest of the server since we rely heavily on
Another round of small documentation tweaks and minor cleanups.
^ permalink raw reply [relevance 7%]
* PATH_INFO spec (with regard to ";")
@ 2009-12-10 22:30 Eric Wong
0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2009-12-10 22:30 UTC (permalink / raw)
To: rack-devel; +Cc: mongrel-unicorn, Marc-Andre Cournoyer
I've been notified privately that my changes for PATH_INFO in Unicorn
0.95.2 (which also got into Thin) may not be completely kosher, but I'm
also asking for the Rack team to clarify PATH_INFO for HTTP parser
Upon further reading (and also of the
related-but-not-necessarily-true-for-Rack RFC 3875 section 4.1.5),
I came across this:
Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot
contain path-segment parameters.
First off, Rack already directly contradicts the "the PATH_INFO is not
URL-encoded" part, so Unicorn conforms to Rack specs over RFC 3875.
*But* Rack does not address the "cannot contain path-segment parameters"
part at all. So I (and probably a few other people) would like
clarification on how to handle PATH_INFO when it comes to ";"
Things to keep in mind:
* URI.parse keeps ";" in URI::HTTP#path
This point may not be relevant to us, as PATH_INFO and
URI::HTTP#path should not necessarily be treated as equals
* WEBrick keeps ";" in PATH_INFO
* PEP333 (which Rack is based on) does not go into this level of
detail regarding PATH_INFO and path segments
* PATH_INFO in Rack appears to be based on CGI/1.1 (RFC 3875)
* Again, Rack already contradicts the URL encoding rules of RFC 3875
for PATH_INFO, so there is precedence for Rack contradicting more
of RFC 3875...
* Rack::Request#full_path only looks at PATH_INFO + QUERY_STRING,
this means many Rack applications may never see the ";" parts
if Thin and Unicorn revert to old behavior.
* Rack does not require REQUEST_URI, this is an extension Unicorn
and Thin both carried over from Mongrel.
* None of the official rack/rack-contrib middleware use REQUEST_URI
Of course, in the grand scheme of things, hardly anybody uses ";" in
paths. Yay for rare corner cases making our lives difficult.
Unicorn mailing list - email@example.com
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [relevance 5%]
Results 1-2 of 2 | reverse results
2009-12-07 10:01 [ANN] unicorn 0.95.2 - small HTTP parser fixes Eric Wong
2009-12-10 22:30 PATH_INFO spec (with regard to ";") Eric Wong
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
Archives are clonable:
git clone --mirror https://bogomips.org/unicorn-public
git clone --mirror http://ou63pmih66umazou.onion/unicorn-public
Example config snippet for mirrors
Newsgroups are available over NNTP:
note: .onion URLs require Tor: https://www.torproject.org/
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git