[multiple inline responses]
Rainer Jung wrote:
> I doubt that such URLs are invalid - not based on any code inspection,
> but simply on the fact that mod_jk decoded percent encoding before
> forwarding for a long time (5.5 years, from Oct. 2001 to May 2007,
> version 1.2.0 to 1.2.22). Since versio
On 18/02/2013 11:44, André Warnier wrote:
> Mark Thomas wrote:
>> On 18/02/2013 09:54, Rainer Jung wrote:
>>> On 17.02.2013 23:57, André Warnier wrote:
>>
Otherwise, my feeling is that it will cost you quite a number of beers
to stop Mark from fixing what could potentially be a security i
Mark Thomas wrote:
On 18/02/2013 09:54, Rainer Jung wrote:
On 17.02.2013 23:57, André Warnier wrote:
Otherwise, my feeling is that it will cost you quite a number of beers
to stop Mark from fixing what could potentially be a security issue, now
that he's sniffed it.
:)
Not sure whether Mark
On 18/02/2013 09:54, Rainer Jung wrote:
> On 17.02.2013 23:57, André Warnier wrote:
>> Otherwise, my feeling is that it will cost you quite a number of beers
>> to stop Mark from fixing what could potentially be a security issue, now
>> that he's sniffed it.
>
> :)
>
> Not sure whether Mark's sn
On 17.02.2013 23:57, André Warnier wrote:
> Mike Wilson wrote:
>> Mark Thomas wrote:
>>> On 17/02/2013 16:54, André Warnier wrote:
Mike Wilson wrote:
>>>
>>>
> Example 2: path /ä in "binary" Unicode
> GET /.. [0xC3,0xA4]
> request.getRequestURI() -> "/.." [0xC3,0xA4]
> r
On 17.02.2013 23:00, Mike Wilson wrote:
> Mark Thomas wrote:
>> On 17/02/2013 16:54, André Warnier wrote:
>>> Mike Wilson wrote:
>>
>>
>>
Example 2: path /ä in "binary" Unicode
GET /.. [0xC3,0xA4]
request.getRequestURI() -> "/.." [0xC3,0xA4]
request.getPathInfo() -> "/ä
Mike Wilson wrote:
Mark Thomas wrote:
On 17/02/2013 16:54, André Warnier wrote:
Mike Wilson wrote:
Example 2: path /ä in "binary" Unicode
GET /.. [0xC3,0xA4]
request.getRequestURI() -> "/.." [0xC3,0xA4]
request.getPathInfo() -> "/ä"
I believe that your example #2 above is simply
Mark Thomas wrote:
> On 17/02/2013 16:54, André Warnier wrote:
> > Mike Wilson wrote:
>
>
>
> >> Example 2: path /ä in "binary" Unicode
> >> GET /.. [0xC3,0xA4]
> >> request.getRequestURI() -> "/.." [0xC3,0xA4]
> >> request.getPathInfo() -> "/ä"
>
>
>
> > I believe that your example #
Mike Wilson wrote:
...
Example 2: path /ä in "binary" Unicode
GET /.. [0xC3,0xA4]
To nitpick : this is not "binary Unicode". It is simply non-URL-encoded, raw UTF-8, which
is itself an encoding of Unicode.
The Unicode "codepoint" of "ä" is 0xE4 (decimal 228), usually represented as
U+00
On 17/02/2013 16:54, André Warnier wrote:
Mike Wilson wrote:
Example 2: path /ä in "binary" Unicode
GET /.. [0xC3,0xA4]
request.getRequestURI() -> "/.." [0xC3,0xA4]
request.getPathInfo() -> "/ä"
I believe that your example #2 above is simply illegal.
One is not supposed to send
Mike Wilson wrote:
Hi Chris,
I'm aware of the two levels of encoding but I'm wondering whether
servlet specification writers were :-)
Here are two examples from Tomcat 7 running with URIEncoding="UTF-8".
Example 1: path /ä in URL-encoded Unicode as sent from browser
GET /%C3%A4
request.ge
Hi Chris,
I'm aware of the two levels of encoding but I'm wondering whether
servlet specification writers were :-)
Here are two examples from Tomcat 7 running with URIEncoding="UTF-8".
Example 1: path /ä in URL-encoded Unicode as sent from browser
GET /%C3%A4
request.getRequestURI() -> "/%C3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mike,
On 2/14/13 9:51 AM, Mike Wilson wrote:
> I can see that even if you specify URIEncoding=UTF-8 in
> server.xml, calls to HttpServletRequest.getRequestURI() will still
> return an undecoded String. (This is probably because of the
> "specificati
I can see that even if you specify URIEncoding=UTF-8 in server.xml,
calls to HttpServletRequest.getRequestURI() will still return an
undecoded String. (This is probably because of the "specification
text" in javadoc: "The web container does not decode this String.")
My question is if this behaviou
14 matches
Mail list logo
