unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* PATH_INFO spec (with regard to ";")
@ 2009-12-10 22:30  5% 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

Hi all,

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.

Eric Wong
Unicorn mailing list - mongrel-unicorn@rubyforge.org
Do not quote signatures (like this one) or top post when replying

^ permalink raw reply	[relevance 5%]

* [ANN] unicorn 0.95.2 - small HTTP parser fixes
@ 2009-12-07 10:01  7% Eric Wong
  0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2009-12-07 10:01 UTC (permalink / raw)
  To: 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.

* http://unicorn.bogomips.org/
* email: mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git
* finger: unicorn@bogomips.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.

Eric Wong

^ permalink raw reply	[relevance 7%]

Results 1-2 of 2 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2009-12-07 10:01  7% [ANN] unicorn 0.95.2 - small HTTP parser fixes Eric Wong
2009-12-10 22:30  5% PATH_INFO spec (with regard to ";") Eric Wong

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).