- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 31 Mar 2013 18:38:23 +0200
- To: Ken Murchison <murch@andrew.cmu.edu>
- CC: ietf-http-wg@w3.org
On 2013-03-28 20:36, Ken Murchison wrote: > Hi All, > > Sec 1, para 2: The phrase "obsoleting those parts previously defined in > [RFC2616]" seems unnecessary since the document boilerplate already > states as such. Also, parts 4 and 6 which similarly describe optional > facilities don't bother with such text. > > Sec 2.1, postscript to suffix-byte-range-spec ABNF: The sentence > immediately following the description of how to handle a representation > shorter than the suffix-length begins with "For example..." . One would > think that the example would demonstrate over-sized suffix-length case, > but it doesn't. I don't think such an example is needed, but I think > the wording is misleading. I would suggest removing the "For > example..." sentence and replacing it with "Examples of > byte-ranges-specifier values:" or "Additional examples of > byte-ranges-specifier values:" or "Examples of byte-ranges-specifier > values using suffix-byte-range-spec:" like is done for the discussion of > byte-range-spec. > > Sec 4.4, Note: suggest changing "... many implementations will simply > respond with 200 (OK) ..." -> "... many implementations will simply > respond with the entire selected representation in a 200 (OK) response ..." -> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2217> > General implementation question that I didn't find answered in the > document: Can a server that receives a request for multiple ranges > reply with only a single part corresponding to the first satisfiable > range? Or can it coalesce all satisfiable ranges into a single part > regardless of the overlaps/gaps? Good question. A perfect client will understand whatever, as the message is self-describing. In practice, clients might get confused if they don't get exactly what they asked for. Best regards, Julian
Received on Sunday, 31 March 2013 16:38:57 UTC