>> The '+' char has no special meaning in HTTP/1.1 (RFC 2616) [1], so in
>> the path part of the URL it just means itself, the plus sign.
>
> Any bug in either mod_alias or mod_jk could be proven with regard to the
> above statement by simply changing the URL from:
>
> http://localhost/sites/one%2B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Konstantin,
On 1/13/2010 6:42 PM, Konstantin Kolinko wrote:
> Why is '+' decoded to ' ' in the path part of the URL?
>
> That is, I think, wrong.
>
> The '+' char has no special meaning in HTTP/1.1 (RFC 2616) [1], so in
> the path part of the URL it
> Is UTF-8 the reason why you are using your custom decoding?
> [...]
> You should be able to use HttpServletRequest.getPathInfo() to get the
> decoded value.
Not really. I could probably be using getPathInfo() for getting the
decoded request. But note that I am also decoding both the former urls
2010/1/14 Tero Karttunen :
>> Why is '+' decoded to ' ' in the path part of the URL?
>> That is, I think, wrong.
>
> This is an interesting theory. If true, it could provide an
> explanation to the observed behavior, but I cannot completely follow
> it.
>
>> The '+' char has no special meaning in H
> Why is '+' decoded to ' ' in the path part of the URL?
> That is, I think, wrong.
This is an interesting theory. If true, it could provide an
explanation to the observed behavior, but I cannot completely follow
it.
> The '+' char has no special meaning in HTTP/1.1 (RFC 2616) [1], so in
> the pa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 1/13/2010 5:51 PM, Mark Thomas wrote:
> On 13/01/2010 22:47, Tero Karttunen wrote:
>> Thank you for another reply, Chris! I was secretly hoping that
>> somebody would stand up and tell me that I have missed something
>> obvious, but the more
2010/1/11 Tero Karttunen :
> Apache Tomcat access log:
> 131.177.146.160 - - [11/Jan/2010:12:58:04 +0200] "GET
> /ts_core_virtual_repository/TeamCenterEmulator/sites/one+one%3cfive
> HTTP/1.1" 200 399
> What my application actually sees after decoding: sites/one onehttp://tools.ietf.org/html/rfc261
On 13/01/2010 22:47, Tero Karttunen wrote:
> Thank you for another reply, Chris! I was secretly hoping that
> somebody would stand up and tell me that I have missed something
> obvious, but the more I look into this issue, the messier it seems.
> But let's not get ahead of things.
>
> I apologize
Thank you for another reply, Chris! I was secretly hoping that
somebody would stand up and tell me that I have missed something
obvious, but the more I look into this issue, the messier it seems.
But let's not get ahead of things.
I apologize for the inconsistency in the log lines I posted in my
e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tero,
On 1/11/2010 8:41 AM, Tero Karttunen wrote:
>
[snip]
> RedirectMatch ^/sites(.*)$ /contextroot/subcontext/sites$1
[snip]
> OBSERVED BEHAVIOR WITH +ForwardURIProxy: (implicit)
> =
> I try to access URL http:
SHORT SUMMARY:
===
When Apache HTTPD is used for both URL manipulation (request
redirecting) and load-balancing with mod_jk, the plus-characters seem
to behave strangely during character re-encoding. Is this a bug or a
feature, and how should the system be set up to ensure correct
opera
11 matches
Mail list logo
