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
use
Accept: text/plain; penalty=0; size=0.23; degradation=0.5
Clearly the ideas have been thought out a lot more than the syntactic
details.
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.
Dan