Hello, it's me again,
Phillip J. Eby wrote:
> MoinMoin, for example, has its own encoding scheme for handling
> pseudo-slashes in paths, and IMO it's a better way to handle it than
> trying to rely on finding a server that supports *not* decoding URLs.
I had the abstract knowledge that CGI is
Brian Smith wrote:
> Ian Bicking wrote:
>
>> We encountered it with GData too, as it uses URLs like
>> /{http:%2f%2fexample.com}term/. But if you balance the {}'s
>> you can parse it out.
>
> Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
> really require them to be un
Ian Bicking wrote:
> We encountered it with GData too, as it uses URLs like
> /{http:%2f%2fexample.com}term/. But if you balance the {}'s
> you can parse it out.
Unquoted curly braces are illegal in any kind of URI or IRI. Does GData
really require them to be unquoted?
- Brian
__
Phillip J. Eby wrote:
> At 09:15 AM 1/23/2008 -0800, Robert Brewer wrote:
>> I consider it a bug in both, and the difficulty level of changing the
>> CGI behavior really has no bearing on our decision to do better with
>> WSGI. I think it's important that we allow the full range of URI's to be
>> a
Luis Bruno wrote:
>> I made note of this issue on the WSGI 2.0 ideas page
> Didn't find it here: http://wsgi.org/wsgi/WSGI_2.0>. Should I look
> elsewhere?
I thought I had added it there, but wrote that when I was offline and
couldn't check. I added a section about it (a very brief section,
t
At 09:15 AM 1/23/2008 -0800, Robert Brewer wrote:
>I consider it a bug in both, and the difficulty level of changing the
>CGI behavior really has no bearing on our decision to do better with
>WSGI. I think it's important that we allow the full range of URI's to be
>accepted. If you go and stick Apa
James Y Knight wrote:
> ...as there is simply no way to represent "some%2Fthing/
> shallow/" with PATH_INFO, as specified in the CGI spec, the only
> alternative is to reject the request. This is what the major servers
> do today.
>
> > Anyone else thinks it's a bug in WSGI too?
>
> WSGI is based
On Jan 22, 2008, at 5:33 PM, Luis Bruno wrote:
> A quick sanity check here: I think
> http://host/catalog/some%2Fthing/shallow/ is *meant* to have two
> nested levels: "some/thing" and "shallow". Is it obvious to you to
> interpret the URL as having three nested levels "some", "thing" and
> "shallo
Ian Bicking pointed at CGI 1.1 saying: "See? The WSGI spec tells me to
do this!" And he's right. This sub-thread is about *me* thinking the
*WSGI spec* should be *fixed*.
James Y Knight wrote:
> Where does the CGI spec forbid multiple segments in PATH_INFO?
> It doesn't. It actually says that PAT
On Jan 22, 2008, at 1:02 PM, Luis Bruno wrote:
>
> Fortunately, the URI spec doesn't repeat the mistake of forbidding
> %-encoding characters. It does mention that each path-segment should
> be
> separately %-decoded, going against the CGI spec which actually
> forbids
> multiple segments *in
Brian Smith wrote:
> If you really want PATH_INFO to have "%2F" instead of "/", then I
> suggest encoding the slashes as "%252F" or "$2F" or something else.
> Then your application will be portable.
I need those '/'. They are the canonical hierarchical delimiters. They
are also present in some
Luis Bruno wrote:
> Brian Smith wrote:
> > An ammendment that recommends, but does not require,
> > REQUEST_URI is a much better option.
>
> Thereby forcing me to shop around for a WSGI server that
> actually puts the recommendation into practice? Because I
> want to keep my %-encoded character
Brian Smith wrote:
> An ammendment that recommends, but does not require, REQUEST_URI is a
> much better option.
Thereby forcing me to shop around for a WSGI server that actually puts
the recommendation into practice? Because I want to keep my %-encoded
characters? Which I encoded for, you know
Luis Bruno wrote:
> Ian Bicking wrote:
> > But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and
> > having the information in duplicate places can lead to errors and
> > unclear situations if they don't match up properly.
I don't understand this argument. WSGI gateways just need to
On Jan 22, 2008, at 6:47 AM, Sven Berkvens-Matthijsse wrote:
> Luís Bruno wrote:
>> Ian Bicking wrote:
>>> But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and
>>> having the information in duplicate places can lead to errors and
>>> unclear situations if they don't match up properl
James Y Knight escreveu:
> FWIW, I think the right thing for a server to do is to reject any URLs
> going to a wsgi (or cgi) script with a %2F in it. I believe this is
> what apache's CGI host does.
You'd reject the following URL?
http://localhost:5000/catalog/NEC/Laptops/LN500%2F9DW/
BTW, I mak
Luís Bruno wrote:
> Ian Bicking wrote:
> > But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and
> > having the information in duplicate places can lead to errors and
> > unclear situations if they don't match up properly.
>
> True, and you can apply the same reasoning to my suggest
Ian Bicking wrote:
> But relating REQUEST_URI with SCRIPT_NAME/PATH_INFO is awkward and
> having the information in duplicate places can lead to errors and
> unclear situations if they don't match up properly.
True, and you can apply the same reasoning to my suggestion too.
Apart from the dupl
Luis Bruno wrote:
> Robert Brewer wrote:
> > > IMHO [changing CP's wsgiserver to do decoding] is the wrong answer
> > Why?
> >
> Because then I'm stuck monkey patching every WSGI server (and/or stuck
> using my own URL dispatcher) so that I don't lose the information that
> one of the forward slash
Luis Bruno wrote:
> Hello y'all, delurking,
>
> I'm using a /-delimited path, %-encoding each literal '/' appearing in
> the path segments. I was not amused to see egg:Paste#http urldecoding
> the whole PATH_INFO.
Unfortunately this is in the WSGI spec, so it's not Paste#http so much
as WSGI t
I'll top post my "solution"; scare quoted because I'm still not sure
this is the smartest idea:
environ['wsgiorg.path-segments'] = ['catalog', 'NEC', 'Computers',
'Laptop', 'LN500/9DW']
Robert Brewer wrote:
> All HTTP URI are /-delimited, and any '/' appearing in a single segment
> that is not i
Luis Bruno wrote:
> I'm using a /-delimited path, %-encoding each literal '/' appearing in
> the path segments. I was not amused to see egg:Paste#http urldecoding
> the whole PATH_INFO.
All HTTP URI are /-delimited, and any '/' appearing in a single segment
that is not intended to participate in t
Hello y'all, delurking,
I'm using a /-delimited path, %-encoding each literal '/' appearing in
the path segments. I was not amused to see egg:Paste#http urldecoding
the whole PATH_INFO.
Ben Bangert wrote:
> This recently became an issue, when a user noticed that the %2B URL
> encoding for a +
Ben Bangert wrote:
> I unfortunately couldn't find anything in the WSGI spec to indicate
> whether or not I could expect environ variables relating to the URL to
> be URL decoded when I get them or whether they reflect the raw URL
> that was sent to the browser.
>
> This recently became an issue,
I unfortunately couldn't find anything in the WSGI spec to indicate
whether or not I could expect environ variables relating to the URL to
be URL decoded when I get them or whether they reflect the raw URL
that was sent to the browser.
This recently became an issue, when a user noticed that
25 matches
Mail list logo
