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