* PATH_INFO spec (with regard to ";")
@ 2009-12-10 22:30 Eric Wong
2009-12-11 0:03 ` James Tucker
2009-12-13 20:04 ` macournoyer
0 siblings, 2 replies; 11+ messages in thread
From: Eric Wong @ 2009-12-10 22:30 UTC (permalink / raw)
To: rack-devel; +Cc: Marc-Andre Cournoyer, mongrel-unicorn
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
implementers.
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-10 22:30 PATH_INFO spec (with regard to ";") Eric Wong
@ 2009-12-11 0:03 ` James Tucker
2009-12-11 0:19 ` Iñaki Baz Castillo
2009-12-13 20:04 ` macournoyer
1 sibling, 1 reply; 11+ messages in thread
From: James Tucker @ 2009-12-11 0:03 UTC (permalink / raw)
To: rack-devel
[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]
On 10 Dec 2009, at 22:30, Eric Wong wrote:
> 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
> implementers.
>
>
> 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
* http://twistedmatrix.com/trac/ticket/1361
* http://jira.codehaus.org/browse/JETTY-980 (although not directly relevant, may be food for thought)
* http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1994q1.messages/3.html (ancient history)
* http://code.google.com/p/googleappengine/issues/detail?id=1340
> Of course, in the grand scheme of things, hardly anybody uses ";" in
> paths. Yay for rare corner cases making our lives difficult.
Amen, because I feel like I want to say "be configurable", given all of the above.
>
> --
> Eric Wong
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-11 0:03 ` James Tucker
@ 2009-12-11 0:19 ` Iñaki Baz Castillo
2009-12-13 13:41 ` James Tucker
2009-12-14 18:51 ` Eric Wong
0 siblings, 2 replies; 11+ messages in thread
From: Iñaki Baz Castillo @ 2009-12-11 0:19 UTC (permalink / raw)
To: rack-devel
El Viernes, 11 de Diciembre de 2009, James Tucker escribió:
> > Of course, in the grand scheme of things, hardly anybody uses ";" in
> > paths. Yay for rare corner cases making our lives difficult.
>
> Amen, because I feel like I want to say "be configurable", given all of the
> above.
I'm coding a XCAP server using Rack. XCAP is basically XPath over HTTP in
which there are HTTP URI's like the following:
/auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
After reading RFC for URI and HTTP I think that the ";" is valid into the
above URI. I also asked in a XCAP maillist and received same conclusion.
Please tell me if you consider the ";" in the above URI wrong.
Regards.
--
Iñaki Baz Castillo <ibc@aliax.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-11 0:19 ` Iñaki Baz Castillo
@ 2009-12-13 13:41 ` James Tucker
2009-12-13 15:15 ` Iñaki Baz Castillo
2009-12-14 0:44 ` Iñaki Baz Castillo
2009-12-14 18:51 ` Eric Wong
1 sibling, 2 replies; 11+ messages in thread
From: James Tucker @ 2009-12-13 13:41 UTC (permalink / raw)
To: rack-devel
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On 11 Dec 2009, at 00:19, Iñaki Baz Castillo wrote:
> El Viernes, 11 de Diciembre de 2009, James Tucker escribió:
>>> Of course, in the grand scheme of things, hardly anybody uses ";" in
>>> paths. Yay for rare corner cases making our lives difficult.
>>
>> Amen, because I feel like I want to say "be configurable", given all of the
>> above.
>
> I'm coding a XCAP server using Rack. XCAP is basically XPath over HTTP in
> which there are HTTP URI's like the following:
>
> /auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
>
> After reading RFC for URI and HTTP I think that the ";" is valid into the
> above URI. I also asked in a XCAP maillist and received same conclusion.
>
> Please tell me if you consider the ";" in the above URI wrong.
"Wrong" is hard to define with archaic protocol specifications that do not match "common" usage patterns, which is why I suggested it should be configurable. I would probably suggest to you that you make your client configurable to escape it's semi-colon characters in the uri that are not part of query syntax.
>
> Regards.
>
>
>
> --
> Iñaki Baz Castillo <ibc@aliax.net>
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-13 13:41 ` James Tucker
@ 2009-12-13 15:15 ` Iñaki Baz Castillo
2009-12-14 0:44 ` Iñaki Baz Castillo
1 sibling, 0 replies; 11+ messages in thread
From: Iñaki Baz Castillo @ 2009-12-13 15:15 UTC (permalink / raw)
To: rack-devel
El Domingo, 13 de Diciembre de 2009, James Tucker escribió:
> On 11 Dec 2009, at 00:19, Iñaki Baz Castillo wrote:
> > El Viernes, 11 de Diciembre de 2009, James Tucker escribió:
> >>> Of course, in the grand scheme of things, hardly anybody uses ";" in
> >>> paths. Yay for rare corner cases making our lives difficult.
> >>
> >> Amen, because I feel like I want to say "be configurable", given all of
> >> the above.
> >
> > I'm coding a XCAP server using Rack. XCAP is basically XPath over HTTP in
> > which there are HTTP URI's like the following:
> >
> > /auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
> >
> > After reading RFC for URI and HTTP I think that the ";" is valid into the
> > above URI. I also asked in a XCAP maillist and received same conclusion.
> >
> > Please tell me if you consider the ";" in the above URI wrong.
>
> "Wrong" is hard to define with archaic protocol specifications that do not
> match "common" usage patterns, which is why I suggested it should be
> configurable. I would probably suggest to you that you make your client
> configurable to escape it's semi-colon characters in the uri that are not
> part of query syntax.
Yes, modifications in the client could be an option. However I cannot force to
every XCAP clients to escape ";" when it's allowed as per URI BNF grammar.
--
Iñaki Baz Castillo <ibc@aliax.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-10 22:30 PATH_INFO spec (with regard to ";") Eric Wong
2009-12-11 0:03 ` James Tucker
@ 2009-12-13 20:04 ` macournoyer
2009-12-13 20:49 ` Eric Wong
1 sibling, 1 reply; 11+ messages in thread
From: macournoyer @ 2009-12-13 20:04 UTC (permalink / raw)
To: Rack Development
"not completely kosher" as in security issue? Should I revert this
change in Thin?
On Dec 10, 5:30 pm, Eric Wong <normalper...@yhbt.net> wrote:
> 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
> implementers.
>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-13 20:04 ` macournoyer
@ 2009-12-13 20:49 ` Eric Wong
0 siblings, 0 replies; 11+ messages in thread
From: Eric Wong @ 2009-12-13 20:49 UTC (permalink / raw)
To: rack-devel
macournoyer <macournoyer@gmail.com> wrote:
> "not completely kosher" as in security issue? Should I revert this
> change in Thin?
Not a security issue, but it violates the CGI/1.1 RFC which Rack is
somewhat based on (but also not tied to).
--
Eric Wong
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-13 13:41 ` James Tucker
2009-12-13 15:15 ` Iñaki Baz Castillo
@ 2009-12-14 0:44 ` Iñaki Baz Castillo
2009-12-14 11:08 ` James Tucker
1 sibling, 1 reply; 11+ messages in thread
From: Iñaki Baz Castillo @ 2009-12-14 0:44 UTC (permalink / raw)
To: rack-devel
El Domingo, 13 de Diciembre de 2009, James Tucker escribió:
> "Wrong" is hard to define with archaic protocol specifications that do not
> match "common" usage patterns
I've re-checked URI/HTTP grammar and the following URI (containing semicolon)
is valid for me (perhaps I'm wrong):
/auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
So, why do you say "archaic protocol specifications that do not match 'common'
usage patterns"?
I expect that HTTP is not just for web servers.
But as I said I could be wrong. Please if you (or someone) can verify me that
the semicolon is invalid according to URI/HTTP BNF grammar, then I would
accept it.
Regards.
--
Iñaki Baz Castillo <ibc@aliax.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-14 0:44 ` Iñaki Baz Castillo
@ 2009-12-14 11:08 ` James Tucker
0 siblings, 0 replies; 11+ messages in thread
From: James Tucker @ 2009-12-14 11:08 UTC (permalink / raw)
To: rack-devel
On 14 Dec 2009, at 00:44, Iñaki Baz Castillo wrote:
> El Domingo, 13 de Diciembre de 2009, James Tucker escribió:
>> "Wrong" is hard to define with archaic protocol specifications that do not
>> match "common" usage patterns
>
> I've re-checked URI/HTTP grammar and the following URI (containing semicolon)
> is valid for me (perhaps I'm wrong):
>
> /auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
This appears to be legal according the aggregate grammars in Appendix A of both 2396 and 3986. I don't have time to track down all of the relevant HTTP and CGI rfcs right now, but bug me later and I'll check those too.
> So, why do you say "archaic protocol specifications that do not match 'common'
> usage patterns"?
Things change, indeed between 2396 and 3986 there were quite some changes to the way segments are split in URIs, however, it does not affect this particular issue.
> I expect that HTTP is not just for web servers.
No comment.
> But as I said I could be wrong. Please if you (or someone) can verify me that
> the semicolon is invalid according to URI/HTTP BNF grammar, then I would
> accept it.
According to the URI grammars in RFCs 2396 and 3986 it's fine. As I said above, I have not checked the HTTP and CGI grammars, which may well be different / more restrictive.
>
> Regards.
>
>
> --
> Iñaki Baz Castillo <ibc@aliax.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-11 0:19 ` Iñaki Baz Castillo
2009-12-13 13:41 ` James Tucker
@ 2009-12-14 18:51 ` Eric Wong
2009-12-14 20:50 ` Iñaki Baz Castillo
1 sibling, 1 reply; 11+ messages in thread
From: Eric Wong @ 2009-12-14 18:51 UTC (permalink / raw)
To: rack-devel
Iñaki Baz Castillo <ibc@aliax.net> wrote:
> I'm coding a XCAP server using Rack. XCAP is basically XPath over HTTP in
> which there are HTTP URI's like the following:
>
> /auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
>
> After reading RFC for URI and HTTP I think that the ";" is valid into the
> above URI. I also asked in a XCAP maillist and received same conclusion.
>
> Please tell me if you consider the ";" in the above URI wrong.
Hi Iñaki,
You're missing the point, it's not that ";" is right or wrong. It's
"right" in that it's always been _accepted_ by the Mongrel family of
HTTP parsers. That's not the issue.
The issue is just whether or not the PATH_INFO variable can contain ";"
(a path-segment parameter) in it. RFC 3875 section 4.1.5 states it
cannot:
Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot
contain path-segment parameters.
However, Rack is not governed by RFC 3875 and already deviates from
it when it comes to the "PATH_INFO is not URL-encoded".
--
Eric Wong
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATH_INFO spec (with regard to ";")
2009-12-14 18:51 ` Eric Wong
@ 2009-12-14 20:50 ` Iñaki Baz Castillo
0 siblings, 0 replies; 11+ messages in thread
From: Iñaki Baz Castillo @ 2009-12-14 20:50 UTC (permalink / raw)
To: rack-devel
El Lunes, 14 de Diciembre de 2009, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > I'm coding a XCAP server using Rack. XCAP is basically XPath over HTTP in
> > which there are HTTP URI's like the following:
> >
> > /auid/global/mydoc.xml/~~/ruleset/rule%5b@id=%22sip:dom.org;p=abc%22%5d
> >
> > After reading RFC for URI and HTTP I think that the ";" is valid into the
> > above URI. I also asked in a XCAP maillist and received same conclusion.
> >
> > Please tell me if you consider the ";" in the above URI wrong.
>
> Hi Iñaki,
>
> You're missing the point, it's not that ";" is right or wrong. It's
> "right" in that it's always been _accepted_ by the Mongrel family of
> HTTP parsers. That's not the issue.
>
> The issue is just whether or not the PATH_INFO variable can contain ";"
> (a path-segment parameter) in it. RFC 3875 section 4.1.5 states it
> cannot:
>
> Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot
> contain path-segment parameters.
>
> However, Rack is not governed by RFC 3875 and already deviates from
> it when it comes to the "PATH_INFO is not URL-encoded".
Ok, thanks a lot for the clarification.
--
Iñaki Baz Castillo <ibc@aliax.net>
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-12-14 20:50 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-12-10 22:30 PATH_INFO spec (with regard to ";") Eric Wong
2009-12-11 0:03 ` James Tucker
2009-12-11 0:19 ` Iñaki Baz Castillo
2009-12-13 13:41 ` James Tucker
2009-12-13 15:15 ` Iñaki Baz Castillo
2009-12-14 0:44 ` Iñaki Baz Castillo
2009-12-14 11:08 ` James Tucker
2009-12-14 18:51 ` Eric Wong
2009-12-14 20:50 ` Iñaki Baz Castillo
2009-12-13 20:04 ` macournoyer
2009-12-13 20:49 ` Eric Wong
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).