Subject: Legal tokens

From: Jim Witt <[email-masked]>
Date: Tue, 05 Sep 2000 14:20:04 -0400

Can anyone tell me if the following is a legal header ofr a response
from a web server?

   *** [tid=10e 108] Receiving response ( 30/8/2000 14:59:10 )

   HTTP/1.1 200 OK
   Server: Netscape-Enterprise/4.0
   Date: Wed, 30 Aug 2000 19:02:26 GMT
   Content-length: 148
   Content-type: image/gif
   Connection: Close
   Connection: keep-alive

Specifically, it is the 'Connection: Close' followed by 'Connection:
keep-alive' that is in question.

Thanks in advance

Jim Witt
on-site at EC Cubed

---

From: [email-masked] (Koen Holtman)
Date: Wed, 6 Sep 2000 07:25:02 +0200 (MET DST)

>keep-alive' that is in question.

Interesting combination of headers.  Digging through the specs, section
19.7.1 of RFC2068 seems to allow the sending of `Connection:
keep-alive' to initiate a persistent connection with some legacy
HTTP/1.0 clients.  The `Connection: Close' at the same time forces a
non-persistent connection in the case that the client is a 1.1 client.
Nothing seems to forbid the use of both at the same time.

So I think it is legal, even unambiguous.  But the semantics is
strange, so it probably reflects a bug in the server.

>on-site at EC Cubed

Koen.

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 6 Sep 2000 19:28:51 +0200

No, it isn't...

You can't close a connection and at the same time leave it open.....
You also can't close a door and leave it open at the same time......

- Joris
  -----Original Message-----
  From: Jim Witt [mailto:[email-masked]]
  Sent: dinsdag 5 september 2000 20:20
  To: [email-masked]
  Subject: Legal tokens

  Can anyone tell me if the following is a legal header ofr a response from
a web server?

     HTTP/1.1 200 OK

  Thanks in advance

  Jim Witt
  on-site at EC Cubed

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 6 Sep 2000 19:32:29 +0200

If

Connection: Close, keep-alive

is legal, how about

Cache-Control: Public, Private, max-age=30, s-maxage=30

They are both buggy, and from my opinion not to be considered legal.

- Joris

> From: Koen Holtman [mailto:[email-masked]]
> Sent: woensdag 6 september 2000 7:25
> To: Jim Witt
> Cc: [email-masked]
> Subject: Re: Legal tokens
> 
>

---

From: [email-masked] (Julien Pierre)
Date: Wed, 06 Sep 2000 13:14:13 -0700

Jim,

> keep-alive' that is in question.

I'd be interested in learning how you get our web server to generate
such a reply, which certainly appears bogus. Are you using some
third-party plug-in or other server-side application by any chance ; or
is this a response from one of the server built-in functions ?

Thanks.

---

From: [email-masked] (Koen Holtman)
Date: Tue, 12 Sep 2000 07:10:30 +0200 (MET DST)

>They are both buggy, and from my opinion not to be considered legal.

Well, when I say legal I mean legal according to what is written in
the specifications.  Your examples are clearly strange, but the
specifications do not disallow these strange examples, so they are
legal.

Not that I would like to see these things on the wire, mind you.

Koen.

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Tue, 12 Sep 2000 16:37:02 +0200

> Sent: dinsdag 12 september 2000 7:11
> To: Joris Dobbelsteen

Agree,

But although it's not explicitly forbidden by the RFC, logic sense (you know
what I mean) would forbid such constructions. The cache-control example was
from another discussion, and Jeffrey Mogul (& John Strake) agreed such
responses should not be cached by a public cache, since this points to a
buggy server.
But not how do you explain illegal and legal responses?
If you have software that receives in a response the connection header(s)
above, you would suppose the header is buggy and cannot be used. And since
it's not used by the software, can't we just say it's illegal?
And since it's not in a request...

- Joris

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 12 Sep 2000 11:32:35 -0700

[email-masked] (Koen Holtman) writes:

Just to clarify: when we were writing the HTTP/1.1 spec, we made
a decision not to specifically list all of the possible non-compliant
combinations of headers and directives, because the combinatorics
would result in a huge list.

(Please try to use words like "compliant" instead of "legal.")

So there are definitely cases which the spec does not explicitly
say "you MUST NOT do this", yet which any reasonable person who
understood the spec would realize that these cases don't comply
with the intentions behind the spec.

In general, if you aren't sure that the spec allows some combination,
then it's a bad idea to send it, since you have no idea whether
the person who wrote the implementation at the receiving end
understood things the same way that you did.

-Jeff