* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #405 (closed editorial: incorporated)

Opened 22 months ago

Last modified 19 months ago

p5 feedback

Reported by: mnot@pobox.com Owned by: ylafon@w3.org
Priority: normal Milestone: 22
Component: p5-range Severity: In WG Last Call
Keywords: Cc:
Origin: http://www.w3.org/mid/DA86AAEF6E448540808AFA696EA47E5A40069EAF@EXB01-MLT.corp.velocix.com

Description

Misc:

  • I can't find an explicit "MUST not include Content-Range in a response

header when Content-Type is multipart/byteranges"

  • Sect. 3.2/5.2: is "*/*" an acceptable value for Content-Range + 416 ?
  • Sect. 4.1: requirement to serve ranges in the order specified by the

client could be in contrast with the suggestion, a couple of paragraphs afterwards, of combining overlapping ranges (which could imply reordering)

  • Sect. 4.2, last paragraph: "... then the client MAY store ...", isn't

it an implementation detail ?

  • Sect. 7.1: the actual suggestion for reducing the security risk

associated to overlapping ranges is not detailed (as promised in the first paragraph of Sect. 7). Add a back-link to Sect. 4.1 ? Or move the "Server MAY combine requested ranges ..." here ? Further to this point, it would be nice to mandate some preferred behaviour on both senders and/or receivers to simplify interoperability (e.g. senders SHOULD not send overlapping ranges and/or receivers SHOULD always compute the minimum number of ranges needed to satisfy a given range request).

  • Appendix A: I may be missing something obvious, but I can't find any

good reason (i.e. one that is not listed in -p1 Sect. 3.3.2) to avoid stating the Content-Length in the examples.

Editorial:

  • Sect. 5.3: "... send me the part(s) that I'm missing ..." => "... send

me the part(s) I'm requesting ..."

  • Sect. 5.4.2: the preamble to the bulleted list has the attribute

"appropriate" which could be substituted by a less generic wording, like e.g.: "... are all syntactically correct as defined in Section 5.4.1, and at least one of the ranges has non empty intersection with the current resource representation extent, then: ..."

  • Sect. 5.2, last paragraph seems misplaced (does it belong to Sect. 5.4

instead ?)

Typos:

  • Sect. 4.2: "most header" => "most recent header"
  • Sect. 5.2: "request: A" => "request: a"

Change History

comment:1 Changed 21 months ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p5-range@tools.ietf.org to ylafon@w3.org

comment:2 Changed 19 months ago by fielding@gbiv.com

Appendix A: I may be missing something obvious, but I can't find any good reason (i.e. one that is not listed in -p1 Sect. 3.3.2) to avoid stating the Content-Length in the examples.

Added in [2134].

Sect. 5.3: "... send me the part(s) that I'm missing ..." => "... send me the part(s) I'm requesting ..."

Fixed in [2134].

Sect. 5.4.2: the preamble to the bulleted list has the attribute "appropriate" which could be substituted by a less generic wording, like e.g.: "... are all syntactically correct as defined in Section 5.4.1, and at least one of the ranges has non empty intersection with the current resource representation extent, then: ..."

Fixed in [2134].

Sect. 5.2, last paragraph seems misplaced (does it belong to Sect. 5.4 instead ?)

Deleted (redundant) in [2134].

Sect. 4.2: "most header" => "most recent header" Sect. 5.2: "request: A" => "request: a"

Already fixed.

comment:3 Changed 19 months ago by fielding@gbiv.com

From [2135]:

Cleanup on aisle p5. Addresses #405

Don't refer to Range Units as Range Specifiers; move requirements on unknown ranges to the header field definitions. Disentangle the Content-Range ABNF so that it correctly distinguishes between the three different forms in use and does not allow them to be mixed. Use the new ABNF alternatives to simplify the prose.

comment:4 Changed 19 months ago by fielding@gbiv.com

From [2158]:

Require that Content-Range not be generated in the HTTP header block of a multiple part 206 response; addresses #405

Finish editorial cleanup of p5.

comment:5 Changed 19 months ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 22

I can't find an explicit "MUST not include Content-Range in a response header when Content-Type is multipart/byteranges"

Fixed in [2158].

Sect. 3.2/5.2: is "*/*" an acceptable value for Content-Range + 416 ?

No; fixed in [2135].

Sect. 4.1: requirement to serve ranges in the order specified by the client could be in contrast with the suggestion, a couple of paragraphs afterwards, of combining overlapping ranges (which could imply reordering)

Fixed in [2157].

Sect. 4.2, last paragraph: "... then the client MAY store ...", isn't it an implementation detail ?

I assume that was already fixed.

Sect. 7.1: the actual suggestion for reducing the security risk associated to overlapping ranges is not detailed (as promised in the first paragraph of Sect. 7). Add a back-link to Sect. 4.1 ? Or move the "Server MAY combine requested ranges ..." here ?

Further to this point, it would be nice to mandate some preferred behaviour on both senders and/or receivers to simplify interoperability (e.g. senders SHOULD not send overlapping ranges and/or receivers SHOULD always compute the minimum number of ranges needed to satisfy a given range request).

Fixed in [2157].

Note: See TracTickets for help on using tickets.