RE: HTTP/1.1 : Chunking

Hi

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
>[...snip...]
>-> 
>-> 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.

OK.

>
>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..

OK

>
>-> 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.

Cheers

Adrien

>
>---
>Josh Cohen <josh@microsoft.com>
>Program Manager - Internet Technologies 
>
----------------------------------------------------------------------------
------
Adrien de Croy - adrien@qbik.com.  Qbik New Zealand Limited, Auckland, New
Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
----------------------------------------------------------------------------
------

Received on Friday, 30 January 1998 06:07:31 UTC