Re: Comments on HTTP/1.0 Draft 3

On Sep 20,  9:39, Danyel Ceccaldi wrote:
>
> >## 8 ##
> What I understood was that a Http/MIME Gateway will be easy to build
> in both directions, if you use CRLF and multiple lines through LWS at
> the beginning of lines.
>
> So IMHO I would leave the CRLF thing and would say something like:
> It is forbidden for a http header creating application to use the
> multiple line mechanism of MIME.
>
> And in section "Tolerant applications":
> Gateway programs are allowed to use the MIME compatible splitting of
> header lines in http.
> Clients should be tolerant in receiving splitted header lines.
>
> It's not well written, but I think you got my intention.
>
> And for http/1.1 CRLF should be a MUST.

Point taken. I agree with your suggested additions.

> >## 13 ##
> Z39.50

I knew I shouldn't have put ".", I added it at the last minute... But the
point stands for "+" and "-": we don't want to support schemes like GOPHER+
and the like, do we ? If we do, then we also need "_" and many others.

> ## 15 ##
> >servers should apply the robustness principle
> Yes.
> >should be mandatory for clients
> No. Because IMHO the Http URL syntax is well defined and every http request
> should be exact. I don't think it's a good idea if
> HTTP/1.0 GET http://www.w3.org/
> and
> HTTP/1.0 GET http://www.w3.org
> are the same. (above is a request sent to a proxy)
> But this is only a not only rationale. In fact, I don't like the idea.

I don't understand what you mean. To me, http://www.w3.org is just a lax way
of saying http://www.w3.org/, maybe I'm confused.

> ## 16 ##
> ## 17 ##
> In HTTP/1.1 there should be:
> It must generate the first date.

Agreed. A hint of this in HTTP/1.0 wouldn't hurt.

> ## 25 ##
> No. I think for things like LINK it should be allowed.
> And , again, I'm not sure if it is allowed in MIME headers, but if so,
> it should be allowed.
> Anyway, if Multible headers causing confusion, the Server should answer
> appropiate: I do what I think I should, but I'm confused.
> (Robustnesss, Tolerance)

LINK is part of HTTP/1.1, not 1.0. If we need a rule applied to all methods
except LINK in HTTP/1.1, fine, there are several such examples with POST in
the HTTP/1.0 spec. I think my point stands for HTTP/1.0, though.

> ## 29 ##
> No. because every time you find reasons to expand the limit.
> At least, I can easily imagine a 20k header:
> 10 links, each about 1000 chars long,
> A long public key: 2k
> a huge Accept information: 3k
> Other huge stuff: 5k
> And links can defined by authors in their documents and also by
> a machine so you can't be sure, how long that part will be.

Good point. Then we need a timeout. Whether this belongs in the protocol spec
or not, I'm not sure. Surely not in HTTP/1.0 anyway.

> ## 72 ##
> No. The reason was, I believe so, that you should be able to be
> completely anonymous, which means you don't want to provide the
> information if you activated a link from a specific 'hotlist'-page
> or from the browser directly. And, if there are no hints for the
> exact uri of your private information, it will be difficult to
> find, even if it is public accessible.
> Anyway you should be able to hide From and Referer for privacy reasons.

Sure, I'm not questioning the privacy issue. My point is that this issue is
too much emphasized in the spec IMHO: it appears to be of paramount
importance to the newbie who knows little about security, whereas that newbie
would better be paranoid about the weak authorization schemes in HTTP/1.0.

Thanks for your feedback

Jean-Philippe

Received on Wednesday, 20 September 1995 09:23:55 UTC