tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20
Date Tue, 24 Jun 2008 08:38:35 GMT


Jesse Klaasse wrote:
[snip]

> Now, we try the whole link through the JK connector:
> http://localhost/webapp/test[brackets].jsp
> This doesn't work, and results in a 404 error (appearing in both IIS and
> Tomcat's log as test%5Bbrackets%5D.jsp, Tomcat with a 404, IIS with a
> 200).
> 

Thanks for the excellent problem description.
It would appear (from the logs), that there is some double-encoding of 
the URI going on.

To simplify, I will assume that you are starting from a static html 
page, loaded in your browser from the local disk, and that this html 
page contains a link written as href="http://.../test[brackets].jsp".
(Please check this. I know it seems evident, but just to make sure that 
you are not starting from a URl that already has the [ ] pre-encoded..)

I will also assume that %5B and %5D are the correct "% hex hex" encoding 
for the characters "[" and "]" respectively.

What *should* happen is :
- when you click on the link, the browser should encode it into 
"http://.../test%5Bbrackets%5D.jsp" *before* sending it to the server.
That is because "[" and "]" are not within the acceptable ranges for 
unencoded URI characters, and it is normal.
- the server, when receiving this URL, should (immediately) decode it 
back into ".../test[brackets].jsp"; and that should also be what is 
processed, and logged.

But, if somewhere along the line, a piece of code was receiving the 
encoded URI "http://.../test%5Bbrackets%5D.jsp", and decided to 
re-encode it again using the "% hex hex" method, then you would get this 
URI : "http://.../test%255Bbrackets%255D.jsp" (where "%25" is the 
encoded version of "%").
Then the next step would decode this URI back into 
"http://.../test%5Bbrackets%5D.jsp", and that is what the server would 
try to access, what would be logged, and also what you seem to experience.

So, which is the culprit which re-encodes something it should not ?
And is there not some parameter somewhere which forces it to do so ?

André





---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message