Re: #506, was: APPSDIR review of draft-ietf-httpbis-p5-range-24

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Julian,
At 08:27 29-10-2013, Julian Reschke wrote:
thanks a lot for the incoming reviews! I'm tracking them in the WG's trac instance.

Ok. As you understand how things work I'll defer to you on the issues instead of tracking down what has been addressed.

Well, it's optional, and we didn't want to make it a SHOULD. It adds overhead to GET responses, even though only few clients will make range requests.

Ok.

Yes. Do you think this is a problem? Why?

It's the kind of text which generates long threads outside the IETF. Some people can argue that it is a "may" written in uppercase while other people will argue that the plain English says something else. My preference is for the intent of the text to be clear unless there is a good reason not to be clear.

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/505>

That's applicable to several drafts in the set.

"A server that supports range requests MAY ignore or reject a Range header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since both are indications of either a broken client or a deliberate denial of service attack (Section 6.1). A client SHOULD NOT request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data."

..or it can serve the response as multipart/byteranges as requested.

Ok.

   "If the selected representation would have had a Content-Type
    header field in a 200 (OK) response, the server SHOULD generate
    that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above.  When
can the "should" be ignored?  Is the server supposed to generate the

Dunno.

same Content-Type header field in each header area if the selected
representation would have a Content-Type header field for a 200 (OK)
response?

That's what the above says, no?

Ok.

Such as?

What I mean is that what happens is undefined when both sides do not follow the RFC 2119 "should".

Right. Fixed in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2441>.

Ok.

It is supposed to be interpreted per RFC 2119.

It is better to use the uppercase words after the RFC 2119 boilerplate.

Regards,
S. Moonesamy




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]