On 8/24/2011 3:12 PM, Jim Jagielski wrote: > > On Aug 24, 2011, at 3:34 PM, William A. Rowe Jr. wrote: > >> On 8/24/2011 11:42 AM, Jim Jagielski wrote: >>> >>> On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote: >>> >>>> 0-, 40-50 becomes 0- >>> >>>> 0-499, 400-599 becomes 0-599 >>> >>>> 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250 >>> >>> This goes against Roy's recommendation to 416 overlaps… But >>> I do see that an overlap is specifically noted in an example >> >> And... 416 is not identified for this specific purpose, we would need >> to go with 400 or fall back on the 200 full-content solution. >> >>> Until we are *clear* on what we should be doing, spec-wise, I >>> think it's unwise to make assumptions… >>> >>> From the above, I would be more comfortable with >>> >>> 0-, 40-50 ---> 0- >>> 0-499, 400-599 ---> 0-599 >>> 1000-1075, 1025-1088, 200-250, 1051-1100 --> 1000-1088, 200-250, 1051-1100 >>> >>> that it, merge as we can, but never resort... >> >> We should adamantly refuse to serve bytes 1051-1088 twice, no matter >> which scheme we use. >> > > Why? If allowed by the spec, or, at least, not disallowed, then > what is the rationale? After all, the client is expecting it after > it gets bytes 200->250.
The client was malformed, if not malicious. The range 0-,0-,0-,0- is syntactically valid, but the client doesn't deserve four copies.
