httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@avron.ICS.UCI.EDU>
Subject Re: HTTP/1.1 (was Re: Paris)
Date Wed, 15 May 1996 20:50:27 GMT
Keep in mind that the *last* thing we do will be to change the HTTP
version stamp in the messages we send, and that won't occur until after
the IESG has accepted HTTP/1.1 as an RFC.  However, we can implement
everything beforehand as HTTP/1.0 and there won't be any problems.

>> 1) chunked encoding (both for requests (POST, PUT) and responses)
> Only need to support it for requests, since it's our choice what we
> send in responses.

Yep, and even that can be left to mod_actions (I think) and CGI scripts.
We may want to write a module that upgrades old CGI script output.

>> 2) revamped content-negotiation
> No such entity. HTTP/1.1 has only hooks for it. There's no defenition
> in the current spec about what that content negotation should be, only
> what it will look like to caches. We can add ourselves a "Vary:
> {accept-headers}" to mod_negotation, but that's about it. Everything
> else is still in flux. From recent messages on http-wg, it seems that
> even the format for entity tags is not fixed yet.

Yes, this won't be implementable for another two weeks (at best).

>> 3) content-ranges, 206 Partial Content, accept-range, etc.
> Not neccessary to call ourselves HTTP/1.1. It's all just "MAY"s and
> "SHOULD"s not a "MUST"s.


>> 4) TRACE?
> Same here.
>> 5) OPTIONS method
> As well.
>> 6) Cache-control configurability, max-age or min-fresh
> And again. And actually, both those are client->proxy directives, so
> we don't need to worry about them at all.

mod_proxy will require major changes, but that's all.

>> 7) pipelining persistant connections? (17.2.2) also, use the new
>>    persistant connection model, "persist", instead of "keep-alive".
>>    (
> Again. And actually, we'll pipeline correctly now with Keep-Alive, if
> the client wanted to.

This will also change next week -- persistence will be the default for 1.1
and "Connection: close" will turn it off.

>> 8) If-Match (18.26)?  Do we need it if entity tags are optional?
> No. At least, not how I read the spec. Since we never generate an
> entity tag, there is no way a client can ever ask us to match one we
> generated. Therefore, we are safe in not supporting If-Match,
> If-NoneMatch and all the others. On the other hand, we do need
> Unless-Modified-Since, since we send Last-Modified headers.


>> (ha, I see the spec mentions "" in 18.47, too bad that's no 
>> longer a reference to hyperreal :)

bummer, I did that on purpose.

>> Heh, according to 23.4, the only thing we "need" to do is support the 
>> Host: header and absolute URI's in requests, which we do.  Are the above 
>> just "nice" things?  Roy?
> Nope. I don't know about the March 5 version, but the May 2 version
> clearly states at the top of section 23.4 that "This section will
> summarize major differences between versions HTTP/1.0 and HTTP/1.1."
> There are a number (139 pages) of minor differences.
> And actually, we don't support the Host header as per the HTTP/1.1
> spec. 1.1 says we need to send a 400 if a request is tagged as
> HTTP/1.1 (what if it's a higher version; the spec doesn't say. Roy?)
> and doesn't have a Host header.

Only 1.1 (for now).

>> A huge amount of work will be the proxy server however - there are lots 
>> of new conditions to test and pretty headers to send.  All necessary, but 
>> still quite a chore.  
> Well, seeing as how the proxy server doesn't seem to work right with
> HTTP/1.0... we should fix that first. Much of the changes in proxy
> behavior are actually quite simple, unless you want to cache things
> that are negotated or authenticated. But you can be a compliant
> HTTP/1.1 caching proxy without doing that. And if you don't want to be
> caching at all... it's very easy. Just add your name to the Via:
> header and send it on. That's (almost) it.

There will be major changes to the caching sections (and associated
requirements) over the next two weeks.  I'd say focus on getting Apache/1.1
out now as good HTTP/1.0 support, so that two weeks from now we can 
focus on a major HTTP/1.1 push and have it all tested prior to the
RFC acceptance (last week in June, most likely).


View raw message