HttpServletResponse encodeURL does not encode

[Nicholas Ide <id...@nlm.nih.gov>]

With cookies disabled and an active session,
encodeURL is supposed to add the sessionID "if needed".

The javadoc and spec are rather quiet on exactly what
"if needed" means.  The current tomcat implementation
is using scheme, servername, serverport, and context
to try and determine if the URL references the 
current webapp.  

This is an unfortunate implementation.

The values of servername and serverport in particular
depend on whether tomcat is used in conjunction
with a web server and connector details, whether
mod_jk or mod_proxy, and possibly whether the entire
configuration is behind a firewall or load balancer.

Why not have the encodeURL implementation simply encode
(or not) based on cookies and session and
ignore what the URL points to?  Leave it up to the
application programmer to only wrap appropriate
URL's with encodeURL.  I believe this was the JSERV
and (JSDK 2.0) implementation.

--- more details, if you care...

In our configuration,
	url in browser:  
		http://publicface.gov
	our load balancer forwards this to:
		http://some_machine:1080
	apache forwards this (currently mod_jk) to:
		tomcat at some_machine:1180
		
This means there are:
    two possible server_name values (publicface.gov and some_machine)
    three possible server_port values (80, 1080, 1180)
    
Outgoing URL's should go to publicface.gov:80 and be encoded with session id.
But, encodeURL doesn't believe it should encode these url's because
catalina has a different idea about what "this" machine:port are.

It would make much more sense to me if encodeURL would ignore the
scheme/server/port values and encode everything so long as cookies
were disabled.

Is this a catalina "bug"?  "feature"?
What's the rationale?
	

Nick Ide
ClinicalTrials.gov - National Library of Medicine


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: HttpServletResponse encodeURL does not encode

[Bill Barker <re...@verizon.net>]

The encodeURL logic is correct, wrt the Servlet Spec.  The bigger problem
would be that mod_jk isn't using the "Host" header to set the "servername".
Which version of mod_jk are you using?

"Nicholas Ide" <id...@nlm.nih.gov> wrote in message
news:200208222152.g7MLqjQ07924@clin3.nlm.nih.gov...
>
> With cookies disabled and an active session,
> encodeURL is supposed to add the sessionID "if needed".
>
> The javadoc and spec are rather quiet on exactly what
> "if needed" means.  The current tomcat implementation
> is using scheme, servername, serverport, and context
> to try and determine if the URL references the
> current webapp.
>
> This is an unfortunate implementation.
>
> The values of servername and serverport in particular
> depend on whether tomcat is used in conjunction
> with a web server and connector details, whether
> mod_jk or mod_proxy, and possibly whether the entire
> configuration is behind a firewall or load balancer.
>
> Why not have the encodeURL implementation simply encode
> (or not) based on cookies and session and
> ignore what the URL points to?  Leave it up to the
> application programmer to only wrap appropriate
> URL's with encodeURL.  I believe this was the JSERV
> and (JSDK 2.0) implementation.
>
> --- more details, if you care...
>
> In our configuration,
> url in browser:
> http://publicface.gov
> our load balancer forwards this to:
> http://some_machine:1080
> apache forwards this (currently mod_jk) to:
> tomcat at some_machine:1180
>
> This means there are:
>     two possible server_name values (publicface.gov and some_machine)
>     three possible server_port values (80, 1080, 1180)
>
> Outgoing URL's should go to publicface.gov:80 and be encoded with session
id.
> But, encodeURL doesn't believe it should encode these url's because
> catalina has a different idea about what "this" machine:port are.
>
> It would make much more sense to me if encodeURL would ignore the
> scheme/server/port values and encode everything so long as cookies
> were disabled.
>
> Is this a catalina "bug"?  "feature"?
> What's the rationale?
>
>
> Nick Ide
> ClinicalTrials.gov - National Library of Medicine





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>