Re: HTTP Host Request header and TC Connectors]

2002-08-29 Thread jean-frederic clere

Bill Barker wrote:
 - Original Message -
 From: Ryan Lubke [EMAIL PROTECTED]
 To: Tomcat Developers List [EMAIL PROTECTED]
 Sent: Wednesday, August 28, 2002 4:00 PM
 Subject: Re: HTTP Host Request header and TC Connectors]
 
 
 
On Wed, 2002-08-28 at 17:32, Bill Barker wrote:

- Original Message -
From: Ryan Lubke [EMAIL PROTECTED]
To: tcdev [EMAIL PROTECTED]
Sent: Wednesday, August 28, 2002 9:43 AM
Subject: [Fwd: HTTP Host Request header and TC Connectors]



By the way the quote was pulled from section 14.23 of RFC 2616.

=

Hi,

Looking for a little input from the HTTP gurus here.

Given the following:

   If the requested URI does not include an Internet host
name for the service being requested, then the Host header
field MUST be given with an empty value.

So, I'm looking for other interpretations of what the above means.

My interpretation at this point is the serviced targeted by the
request URI is identified via an IP address vs a host name, that
the Host request header will be sent but with an empty value.

Does anyone agree/disagree?

The reason I ask is that if an empty Host header is sent to Tomcat,

 and
 
a redirect is sent back, the value of the Location header is useless,
i.e.  http:///index.jsp.

My reading of 14.23 says that this is exactly what should happen, since

 the
 
only (valid) way that this could happen is if the user originally

 requested
 
http:///.  Since the client was capable of resolving that request, it

 should
 
be able to resolve the value of the Location header.

Actually, the client doesn't request http:///.
Example below.

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET / HTTP/1.1
Host:

HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Date: Wed, 28 Aug 2002 23:01:29 GMT
Transfer-Encoding: chunked
Location: http:///index.html
Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector)

Perhaps I missed your point.
 
 
 My point is that unless you typed http:/// into the URL box of your browser,
 then your client is broken if it sent an empty Host header.  The RFC
 requires that the content of the Host header is the part of the URL after
 the // and before the next / (aka the authority).

The above request is invalid and should be handled as invalid.

TC should not send a redirect in the case.

 
 
I'm trying to determine if this is a problem with the client
implementation's interpretation of the spec, or a problem with Tomcat.

Thanks,

-rl




--
To unsubscribe, e-mail:

mailto:[EMAIL PROTECTED]

For additional commands, e-mail:

mailto:[EMAIL PROTECTED]




--
To unsubscribe, e-mail:

mailto:[EMAIL PROTECTED]

For additional commands, e-mail:

mailto:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:

 mailto:[EMAIL PROTECTED]
 
For additional commands, e-mail:

 mailto:[EMAIL PROTECTED]
 


--
To unsubscribe, e-mail:
 
 mailto:[EMAIL PROTECTED]
 
For additional commands, e-mail:
 
 mailto:[EMAIL PROTECTED]
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 
 




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: HTTP Host Request header and TC Connectors]

2002-08-28 Thread Bill Barker


- Original Message -
From: Ryan Lubke [EMAIL PROTECTED]
To: tcdev [EMAIL PROTECTED]
Sent: Wednesday, August 28, 2002 9:43 AM
Subject: [Fwd: HTTP Host Request header and TC Connectors]


 By the way the quote was pulled from section 14.23 of RFC 2616.

 =

 Hi,

 Looking for a little input from the HTTP gurus here.

 Given the following:

If the requested URI does not include an Internet host
 name for the service being requested, then the Host header
 field MUST be given with an empty value.

 So, I'm looking for other interpretations of what the above means.

 My interpretation at this point is the serviced targeted by the
 request URI is identified via an IP address vs a host name, that
 the Host request header will be sent but with an empty value.

 Does anyone agree/disagree?

 The reason I ask is that if an empty Host header is sent to Tomcat, and
 a redirect is sent back, the value of the Location header is useless,
 i.e.  http:///index.jsp.

My reading of 14.23 says that this is exactly what should happen, since the
only (valid) way that this could happen is if the user originally requested
http:///.  Since the client was capable of resolving that request, it should
be able to resolve the value of the Location header.


 I'm trying to determine if this is a problem with the client
 implementation's interpretation of the spec, or a problem with Tomcat.

 Thanks,

 -rl




 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]




 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: HTTP Host Request header and TC Connectors]

2002-08-28 Thread Ryan Lubke

On Wed, 2002-08-28 at 17:32, Bill Barker wrote:
 
 - Original Message -
 From: Ryan Lubke [EMAIL PROTECTED]
 To: tcdev [EMAIL PROTECTED]
 Sent: Wednesday, August 28, 2002 9:43 AM
 Subject: [Fwd: HTTP Host Request header and TC Connectors]
 
 
  By the way the quote was pulled from section 14.23 of RFC 2616.
 
  =
 
  Hi,
 
  Looking for a little input from the HTTP gurus here.
 
  Given the following:
 
 If the requested URI does not include an Internet host
  name for the service being requested, then the Host header
  field MUST be given with an empty value.
 
  So, I'm looking for other interpretations of what the above means.
 
  My interpretation at this point is the serviced targeted by the
  request URI is identified via an IP address vs a host name, that
  the Host request header will be sent but with an empty value.
 
  Does anyone agree/disagree?
 
  The reason I ask is that if an empty Host header is sent to Tomcat, and
  a redirect is sent back, the value of the Location header is useless,
  i.e.  http:///index.jsp.
 
 My reading of 14.23 says that this is exactly what should happen, since the
 only (valid) way that this could happen is if the user originally requested
 http:///.  Since the client was capable of resolving that request, it should
 be able to resolve the value of the Location header.

Actually, the client doesn't request http:///.  
Example below.

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
GET / HTTP/1.1
Host: 

HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Date: Wed, 28 Aug 2002 23:01:29 GMT
Transfer-Encoding: chunked
Location: http:///index.html
Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector)

Perhaps I missed your point.
 
 
  I'm trying to determine if this is a problem with the client
  implementation's interpretation of the spec, or a problem with Tomcat.
 
  Thanks,
 
  -rl
 
 
 
 
  --
  To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 
 
  --
  To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: HTTP Host Request header and TC Connectors]

2002-08-28 Thread Bill Barker


- Original Message -
From: Ryan Lubke [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, August 28, 2002 4:00 PM
Subject: Re: HTTP Host Request header and TC Connectors]


 On Wed, 2002-08-28 at 17:32, Bill Barker wrote:
 
  - Original Message -
  From: Ryan Lubke [EMAIL PROTECTED]
  To: tcdev [EMAIL PROTECTED]
  Sent: Wednesday, August 28, 2002 9:43 AM
  Subject: [Fwd: HTTP Host Request header and TC Connectors]
 
 
   By the way the quote was pulled from section 14.23 of RFC 2616.
  
   =
  
   Hi,
  
   Looking for a little input from the HTTP gurus here.
  
   Given the following:
  
  If the requested URI does not include an Internet host
   name for the service being requested, then the Host header
   field MUST be given with an empty value.
  
   So, I'm looking for other interpretations of what the above means.
  
   My interpretation at this point is the serviced targeted by the
   request URI is identified via an IP address vs a host name, that
   the Host request header will be sent but with an empty value.
  
   Does anyone agree/disagree?
  
   The reason I ask is that if an empty Host header is sent to Tomcat,
and
   a redirect is sent back, the value of the Location header is useless,
   i.e.  http:///index.jsp.
 
  My reading of 14.23 says that this is exactly what should happen, since
the
  only (valid) way that this could happen is if the user originally
requested
  http:///.  Since the client was capable of resolving that request, it
should
  be able to resolve the value of the Location header.

 Actually, the client doesn't request http:///.
 Example below.

 Trying 127.0.0.1...
 Connected to 127.0.0.1.
 Escape character is '^]'.
 GET / HTTP/1.1
 Host:

 HTTP/1.1 302 Moved Temporarily
 Content-Type: text/html
 Date: Wed, 28 Aug 2002 23:01:29 GMT
 Transfer-Encoding: chunked
 Location: http:///index.html
 Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector)

 Perhaps I missed your point.

My point is that unless you typed http:/// into the URL box of your browser,
then your client is broken if it sent an empty Host header.  The RFC
requires that the content of the Host header is the part of the URL after
the // and before the next / (aka the authority).

 
  
   I'm trying to determine if this is a problem with the client
   implementation's interpretation of the spec, or a problem with Tomcat.
  
   Thanks,
  
   -rl
  
  
  
  
   --
   To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
  
  
  
  
   --
   To unsubscribe, e-mail:
  mailto:[EMAIL PROTECTED]
   For additional commands, e-mail:
  mailto:[EMAIL PROTECTED]
  
 
 
  --
  To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
 



 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: HTTP Host Request header and TC Connectors

2002-08-28 Thread Steve Downey

My understanding is that this is really a client issue, rather than server. By 
the time a connector gets it, it's too late to do much about it.

A little bit of research indicates that the user agents I have about will put 
the IP address in the Host header if the URI is specified by IP. That seems 
the only reasonable thing to do. The name of the host in that case is the IP 
address. 

I suppose that if you were doing something bizzare like HTTP over a unix 
domain socket you wouldn't have a host name of any kind. But that's pretty 
far out there. 

But, on the TC side, I don't think the connector should rewrite the header if 
it's empty.

On Wednesday 28 August 2002 12:26 pm, Ryan Lubke wrote:
 Hi,

 Looking for a little input from the HTTP gurus here.

 Given the following:

If the requested URI does not include an Internet host
 name for the service being requested, then the Host header
 field MUST be given with an empty value.

 So, I'm looking for other interpretations of what the above means.

 My interpretation at this point is the serviced targeted by the
 request URI is identified via an IP address vs a host name, that
 the Host request header will be sent but with an empty value.

 Does anyone agree/disagree?

 The reason I ask is that if an empty Host header is sent to Tomcat, and
 a redirect is sent back, the value of the Location header is useless,
 i.e.  http:///index.jsp.

 I'm trying to determine if this is a problem with the client
 implementation's interpretation of the spec, or a problem with Tomcat.

 Thanks,

 -rl


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]