Subject: status on partitioned drafts

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 13 Nov 2007 15:15:28 -0800

I managed to submit a draft 00 for the first seven parts of my
partitioned HTTP/1.1 specification prior to my trip to ApacheCon
this week.  The drafts can be found at

<https://datatracker.ietf.org/drafts/?filename=draft-fielding-http>

or

<http://labs.apache.org/webarch/http/draft-fielding-http/>

I am tracking progress and comments specific to these drafts
on the Apache tracking system, so feel free to add issues where
you see them.

<http://issues.apache.org/jira/browse/LABS/component/12311588>

The following WG issues are resolved in drafts 00:

[i1] HTTP Version should be case sensitive
[i2] 'unsafe' characters
[i3] Chunk Size Definition
[i4] Message Length
[i5] Via is a MUST
[i6] Fragments allowed in Location
[i7] Editors Notes
[i8] Media type registrations
[i9] Trailer
[i10] Safe Methods vs Redirection
[i11] URI includes query
[i12] Invalidation after Update or Delete
[i14] Clarification regarding quoting of charset values
[i15] No close on 1xx responses
[i16] Remove 'identity' token references
[i17] Revise description of the POST method
[i18] Cache validators in 206 responses
[i45] RFC977 reference
[i47] inconsistency in date format explanation
[i48] Date reference typo
[i49] Connection header text
[i62] Whitespace in quoted-pair

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 14 Nov 2007 13:07:00 +1300

I know it shows issue I5 (Via is a MUST) as closed, but this requirement
sets off many warning bells for me.

I've totally lost count of the number of times a customer has asked
whether there's any way they can ensure their ISP can't see they are
running a proxy server.  Regardless of what any of us feels about the
ethics of ISPs blocking shared access, the customers are expressing a
clear requirement.

For these customers, mandatory insertion of a Via header would be highly
problematic, advertising the fact they are using a proxy.

There are other sorts of proxies as well (such as those commonly used
for satellite access), where users connect through a proxy on localhost,
possibly a split proxy.  I guess it's not such an issue for these.

An intercepting proxy that wishes to maintain transparency can't be
inserting or modifying any headers at all though.

So, I see several reasons why the Via header is problematic - the main
one being customer requirements.  I can only really see one reason why
it could be useful, e.g. to try and debug issues / track down potential
problems.

Am I missing a bunch of use-cases for the Via header?  Is it expected to
be used by upstream caches or servers?

At the moment I'm still strongly inclined to not put it in, or make the
default setting not to put it in.  It's hard enough getting users to do
simple things, trying to explain the ramifications of a header like Via
is a job I'd rather not take on.  Putting a Via header in for responses
is fine though, just the request side is where I see the major problem.

Regards

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Nov 2007 11:25:33 +1100

> sets off many warning bells for me.

As I said previously, those issues aren't quite yet closed in a WG  
sense; now is the time to discuss them.
> inserting or modifying any headers at all though.

'transparency' in HTTP is a confusing term, but I know what you mean.

> be used by upstream caches or servers?

Some proxies use it for loop detection, but that's mostly by checking  
to see if their own identifier shows up already. Others embed  
debugging information in the comment.

I've also been able to discover that public sites use accelerators by  
sending TRACE through to the origin server; even though the  
accelerator wasn't configured to send Via on responses, it did on  
requests, and so it shows up in the TRACE response; sort of the  
opposite case of what you're talking about.

> is fine though, just the request side is where I see the major  

 From what I've seen, many proxies have a number of settings which,  
when turned on, will cause the proxy to become non-conformant; e.g.,  
see squid.conf. I don't know that there's much we can do about this,  
and I'm not feeling particularly motivated to argue against that  
practice now.

OTOH, making this requirement a SHOULD is probably closer to  
reflecting current practice, especially if we were to have some  
explanatory text about it.

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

---

From: David Morris <[email-masked]>
Date: Tue, 13 Nov 2007 16:50:09 -0800 (PST)

I don't think MUST should be used if the protocol's basic purpose
continues to function if the MUST is violated. Protocol specific
decisions aren't made based on the Via: value. Inconvenient for
debugging but no other harm if omitted.

Let's face it ... if someone doesn't was their proxy detected,
they aren't really going to care if it conforms to the standard.
Similarily, if some application wants to look like a proxy but isn't
it can fake a Via: header and is not likely to care about the slap
on the wrist with a wet noodle that not-conformance will engender.

Dave Morris

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 14 Nov 2007 02:16:34 +0100

> explanatory text about it.

+1

There is no reason to have MUST level requirements without any
noticeable impact on the operations of the protocol. And Via is
certainly in that category.

Regards
Henrik

---

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

> certainly in that category.

I would argue we should open a new issue for this one, i5 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i5>) was about 
the inconsistency between SHOULD (14.38) and MUST (14.45). We fixed that 
IMHO correctly (using consistently the stronger requirement).

So if we want to relax the MUST level requirement, that should be 
treated separately...

BR, Julian

---

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

> So if we want to relax the MUST level requirement, that should be 

Yes, it's two separate issues, even if the solution is mutually
exclusive in terms of text change relateive to 2616.

Regards
Henrik

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 15 Nov 2007 15:35:41 +1300

understood.  Sorry I missed that in my original post.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 21 Nov 2007 21:55:09 -0800

> on the Apache tracking system, so feel free to add issues where

I belatedly discovered that the jira issue tracker has the ability
to track versioned releases, but only at the project level, so I have
moved all of my draft issues to their own project:

   <http://issues.apache.org/jira/browse/HTTPDRAFT>

which can now produce automatic changelog, roadmap, and fix-per-version
reports.

Cheers,