You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Ryan Lubke <Ry...@Sun.COM> on 2002/08/28 18:43:31 UTC
[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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: HTTP Host Request header and TC Connectors]
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Bill Barker wrote:
> ----- Original Message -----
> From: "Ryan Lubke" <Ry...@Sun.COM>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> 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" <Ry...@Sun.COM>
>>>To: "tcdev" <to...@jakarta.apache.org>
>>>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:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>For additional commands, e-mail:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>
>>>>
>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>>For additional commands, e-mail:
>>>
>>><ma...@jakarta.apache.org>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>
> <ma...@jakarta.apache.org>
>
>>>For additional commands, e-mail:
>>
> <ma...@jakarta.apache.org>
>
>>
>>
>>--
>>To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: HTTP Host Request header and TC Connectors]
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Ryan Lubke" <Ry...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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" <Ry...@Sun.COM>
> > To: "tcdev" <to...@jakarta.apache.org>
> > 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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: HTTP Host Request header and TC Connectors]
Posted by Ryan Lubke <Ry...@Sun.COM>.
On Wed, 2002-08-28 at 17:32, Bill Barker wrote:
>
> ----- Original Message -----
> From: "Ryan Lubke" <Ry...@Sun.COM>
> To: "tcdev" <to...@jakarta.apache.org>
> 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: HTTP Host Request header and TC Connectors]
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Ryan Lubke" <Ry...@Sun.COM>
To: "tcdev" <to...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>