comments on the HTTP2 spec

Dan Connolly (
Mon, 07 Dec 92 22:50:22 CST

Problem: user A does CHECKOUT doc1
user B does CHECKIN doc1
Result: everybody loses.
Solution: server gives A a "magic cookie" generated at the time
of the checkout. B doesn't have the cookie, so he
can't do a checkin.

Problem: "The response may be straight HTML ... or may
start with
HTTP-Version: ..."
That looks like perfectly legal HTML to me. How
do you tell the difference?
Solution: GET command is only for old servers. It always
returns HTML. For new servers, use DOCUMENT command
(or go to NNTP and use ARTICLE).
(or just don't put "the response may by HTML" in the spec.
put it in the section on tolerated errors)

Problem: how does a server know where the end of PUT data is?
(it can't just wait 'till the connection closes, cuz
it has to send back a status response)
Solution: restrict PUT to 7bit or 8bit encodings, or
introduce a Bytes: header for straight binary.

Issue: Syntax of Accept: line clashes with existing parameter syntax.
The MIME content-type header looks like:

Content-Type: text/plain; charset=us-ascii

We can get rid of the parameters (though in some cases
they're required... hmmm...), but let's use the same
syntax to stick other stuff in there so in stead of

Accept: text/plain, 1, 0, 0


Accept: text/plain; penalty=0; size=0.23; degradation=0.5

Clearly the ideas have been thought out a lot more than the syntactic

On the other hand, the syntactic details of NNTP are a done deal.
I think we could save some time debugging the implementation by
going with NNTP. They've dealt with stuff like a string to identify
a version of a piece of software, and all sorts of other stuff
that's "TBD" in the HTTP2 spec.

We could cut to the chase and get right to the novel features of
HTTP2, with some confidence that the syntactic details are handled.

By the way... I think this NNTP++ protocol should be used in stead
of Gopher+ too.