You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ryan Lubke <Ry...@Sun.COM> on 2002/08/29 17:23:48 UTC

[HttpClient] Host header handling...again

The current behavior where HttpClient will send an empty Host
request-header if the target resource is identified by
an IP address may need to be reworked.  

Given the folloing:

GET / HTTP/1.0
Host: 

Against tomcat will yield a redirect to index.jsp, however
the Location header will look like this:  
   
   Location: http:///index.jsp

This will cause the redirection logic to fail.

After looking at the packets a browser sends, no matter
how the target resource is identified, hostname or IP address,
the Host request-header will be populated with that information of the
URL.

I guess the proper thing to do would be send a non-empty
Host request-header if strict mode is disabled.  Of course
in strict mode, the user's mileage will vary.

I then have a question about strict mode philosophy.  Should
strict mode be enabled by default or only in the cases
where it is expressly requested by the developer using the 
libraries?  If disabled by default, the library should
work 'out of the box' with most server implementations.
Sure, it's only one flag, but it's one less thing a 
developer has to deal with.

Just a thought.






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


Re: [HttpClient] Host header handling...again

Posted by Ortwin Glück <or...@nose.ch>.
Interesting thoughts.

default behaviour:
I think that HttpClient's default behaviour should be that it works in 
most cases without throwing exceptions. This makes integration easier. I 
guess that most users will not care if the protocol had been strict, but 
whether they got a useful response back from the server or not.
Users who do server tests must of course do more work to configure 
HttpClient and evaluate response / exceptions. But this is what they 
would expect isn't it?

I would just file your thoughts as a reminder bug for now and postpone a 
decision to when we have a better idea of this "more detailed config" 
thing. Controlling all those little details with just one big switch 
(strictMode) is very coarse-grained for my taste.

Odi


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