comments on the HTTP2 spec

Dan Connolly <>
Message-id: <>
Subject: comments on the HTTP2 spec
Date: Mon, 07 Dec 92 22:50:22 CST
From: Dan Connolly <>

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.