W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

RE: HTTP/1.1 : Chunking

From: Adrien de Croy <adrien@qbik.com>
Date: Sat, 31 Jan 1998 02:58:09 +1200
Message-Id: <>
To: Josh Cohen <joshco@microsoft.com>, Ben Laurie <ben@algroup.co.uk>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5324

At 03:23 30/01/98 -0800, Josh Cohen wrote:
>-> -----Original Message-----
>-> From: Adrien de Croy [mailto:adrien@qbik.com]
>-> Sent: Thursday, January 29, 1998 11:37 PM
>-> To: Ben Laurie
>-> Cc: http-wg@cuckoo.hpl.hp.com
>-> Subject: Re: HTTP/1.1 : Chunking
>-> 4.2 Message headers
>-> The allowing of multiple headers if their values form a 
>-> single list seems a
>-> redundant complexity.  Unless you are catering for people 
>-> debugging by hand
>-> Personally I would remove allowing this from the spec.  I 
>-> don't believe any
>-> client software would implement it (unless they are 
>-> programming in Pascal or
>-> something with a string length limitation - UGH!).
>Does the spec allow you to collapse multiple headers into
>a single line? If so, you can put them in your name/value
>list just the same.

It does, and that is definitely what I will be doing, but the thing is that
the spec allows it, which means implementors must check for it.

>-> Proxy Authentication.
>-> There are some problems with the proposed method where it 
>-> relates to chained
>-> proxies, or a "use proxy" response.  Basically it may be 
>-> necessary for a
>-> client to include many Proxy-Authorization fields in a 
>-> request, since it is
>-> possible that only the client holds the credentials of the 
>-> proxies involved.
>-> Otherwise ALL agents in the chain (including the end server) 
>-> MUST support
>-> persistent connections.
>-> If it needs multiple authorisation fields, how can each 
>-> proxy tell which one
>-> is intended for it.  It would have to try them all for a 
>-> match, strip it
>-> out, and pass the request on.
>Huh? (put 305 aside for the moment)
>If the client is going through multiple chained (auth requesting )
>proxies then it must include credentials for each of them.
>As a side affect, each credential is readable by all
>proxies in front of it.
>The proxy knows which credential set is for it
>by looking for the realm value that it generated.


>As a former proxy implementor, I am happy to agree that
>the proxy-auth system is a bit ugly and could use some work.
>A proposal to include more specific realm info (for the chained
> case) was rejected because it could cause backward compat problems.

Are these backward compatibility problems real - how many implementations
would need to significantly alter their behavior due to a change here, given
that proxy authentication was not even a part of HTTP/1.0

>-> Multiple byte-range requests?  
>-> Normally I guess these would only be made by caches, as clients would
>-> generally always need the end of a file, rather than chunks 
>-> out of the
>-> middle of it.  Are overlapping byte ranges meant to be 
>Not really.  If a client is doing pipelined range requests,
>it may very well, retreive bits of an entity at a time,
>ie bytes 
>1) 1-100 of entity A
>2) 1-100 of entity B
>3) 1-100 of entity C
>4) 101-200 of entity A
>5) 101-200 of entity B
>6) 101-200 of entity C
>to affect a sort of multiplex...  This is critical
>for user experience to perform well with only 1
>or two connections..


>-> condensed by the
>-> server? or supplied as requested.
>-> Since the protocol is 
>-> changing, why not make
>-> it REAL easy to validate cache files by assigning every 
>-> cachable resource a
>-> globally unique identifier which changes with modifications 
>-> to the resource.
>-> Then a validation would simply involve sending the identifier
>-> Say in the form of URL: File Version, or system file time.  
>-> This would
>-> completely remove the complexity of validation with servers, 
>-> and caches
>-> could still use freshness concepts for efficiency.  It would 
>-> also remove the
>-> dependency on synchronised clocks etc.
>Doesnt Etags meet this requirement?

It would if the presence of ETag was mandatory, and there was some
definition of the content such that the ETag could be compared by the
recipient to determine precedence.

>further, be careful saying that "since the protocol is changing"..
>No, the protocol isnt changing necessarily.  
>We are bound that all changes must be backward compatible.
>Additionally, we are past the time for new features to be added
>in the protocol. (at least in v1.1).  You might look to the extensions
>working group for a mechanism to plug in new features...
>that list is ietf-http-ext@w3.org

Hmmm, OK.

As for backward compatibility, that is pretty subjective.  In software
development, it is more easy (read more reliable) to implement a simple
protocol than one which is backwardly compatible and complex.



>Josh Cohen <josh@microsoft.com>
>Program Manager - Internet Technologies 
Adrien de Croy - adrien@qbik.com.  Qbik New Zealand Limited, Auckland, New
                 See our pages and learn about WinGate at http://www.qbik.com/
Received on Friday, 30 January 1998 06:07:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC