Subject: Intro to Methods making Host header requirement

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Nov 2007 14:14:17 +0100

Hi,

I was just looking at Section 9 
(<http://tools.ietf.org/html/rfc2616#section-9>)...:

    The set of common methods for HTTP/1.1 is defined below. Although
    this set can be expanded, additional methods cannot be assumed to
    share the same semantics for separately extended clients and servers.

    The Host request-header field (section 14.23) MUST accompany all
    HTTP/1.1 requests.
	
...any reason why the Host header requirement is listed here so 
prominently (duplicating text from 14.23)?

Best regards, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 14 Nov 2007 14:33:38 +0100

Julian Reschke wrote:
 
>    The Host request-header field (section 14.23) MUST accompany
>    all HTTP/1.1 requests.
 
> prominently (duplicating text from 14.23)?

Servers are supposed to reject HTTP/1.1 requests without a Host:
header field as broken.  It took me until version 0.7 of a dummy
http://purl.net/xyzzy/httpd404.htm#history "server" to get this
right, some years ago. 

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Nov 2007 14:58:26 +0100

> http://purl.net/xyzzy/httpd404.htm#history "server" to get this

Understood -- I was just wondering why it's mentioned in the intro to 
"Methods" -- wouldn't it better fit into Section 5 (Request)?

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Wed, 14 Nov 2007 07:39:13 -0800 (PST)

> "Methods" -- wouldn't it better fit into Section 5 (Request)?

Certainly at the time a big stick was felt to be necessary to make sure
the feature was supported by all general UAs.

Dave Morris

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 15 Nov 2007 03:18:30 +0100

> the feature was supported by all general UAs.

And now that big stick is not really needed any more.. The requirements
in "5.1.2 Request-URI" and "14.23 Host" is well more than sufficent to
rule out any doubt. Having it duplicated in "9 Method Definitions" is
just confusing for no good reason.

The text in 9 should be moved to "5.3 Request Header Fields" where it
belongs, or deleted.

Regards
Henrik

---

From: Dave Kristol <[email-masked]>
Date: Wed, 14 Nov 2007 16:21:18 +0000

David Morris wrote:
> [...]

More history:  Back then (c.1996) there was great concern that the 
sudden and rapid proliferation of web servers would deplete the IPv4 
address space, because each needed its own address.  The Host header 
enabled virtual servers, which, in turn, made possible IP address 
sharing.  But UAs obviously had to support (i.e., send) the Host header 
for the sharing to work.

Dave Kristol

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Nov 2007 20:26:15 +0100

> The text in 9 should be moved to "5.3 Request Header Fields" where it

And, as a matter of fact, we may need all the big sticks we have for 
some other issues :-).

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 19 Nov 2007 09:30:33 +0100

Julian Reschke wrote:
 
>> The text in 9 should be moved to "5.3 Request Header Fields" where
>> it belongs, or deleted.

> some other issues :-)

Make sure that you don't lose the MUST in section 9.  Out of curiosity,
what's the intended status for 2616bis, STD, DS, PS, or "let's see what
happens" ?

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Nov 2007 09:41:40 +0100

> Make sure that you don't lose the MUST in section 9.  Out of curiosity,

My proposal would be to move it to a place where it makes more sense.

> what's the intended status for 2616bis, STD, DS, PS, or "let's see what

<http://www.ietf.org/html.charters/httpbis-charter.html> says DS. I'm 
not sure that we have given up hope to reach STD, but that would require 
making some stuff downrefs (such as MIME and the compression schemes).

Best regards, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 19 Nov 2007 12:11:15 +0100

Julian Reschke wrote:

 [Host: MUSTard in ch. 9]
> My proposal would be to move it to a place where it makes more sense.

+1

 [STD, DS, PS, or "let's see what happens" ?]
> <http://www.ietf.org/html.charters/httpbis-charter.html> says DS.

Ugh, I never looked into the "goals" before.

> I'm not sure that we have given up hope to reach STD, but that would
> require making some stuff downrefs (such as MIME and the compression
> schemes).

RFC 1950 up to 1952 are informational, if you want them as "normative"
that's anyway a downref.

You can replace 2048 by 4288 + 4289, as BCP that would be no downref.
RFC 1766 is now RFC 4646, also a BCP.  No idea what "H.5" tries to say.

RFC 1864 is a DS (didn't know this, funny), if you need an STD we could
try to promote it.  Nobody's going to modify Content-MD5, my crystal-
ball says.

RFC 2396 is now 3986 (STD 66).  RFC822ABNF will go (4234bis is an STD).
I think that leaves 2617bis, 2822upd, and the rest of MIME as downrefs.

BTW, the draft mentions WAIS (the protocol), RFC 4156 says that WAIS
(the URI-scheme) is "historic".  How about removing that cruft ?

 Frank

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 19 Nov 2007 12:58:58 +0100

On mån, 2007-11-19 at 09:30 +0100, Frank Ellermann wrote:

> Make sure that you don't lose the MUST in section 9.

It's redundant. This MUST level requirement is in both "5.1.2
Request-URI" and "14.23 Host" with slightly different wording.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Nov 2007 21:21:32 -0800

Now i91; <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/ 
#i91> (editorial).

On 14/11/2007, at 5:14 AM, Julian Reschke wrote:

>
> Hi,
>
> I was just looking at Section 9 (<http://tools.ietf.org/html/ 
> rfc2616#section-9>)...:
>

--
Mark Nottingham     http://www.mnot.net/