RE: Coalescing ranges

I can add that we implemented range coalescing in http.sys several releases back.  We found that a major application could no longer open files hosted on IIS servers, and had to back it out.  Don't know if current versions of that application are as demanding about getting back exactly the ranges it asked for....  We do a little bit of coalescing still, but it's much less aggressive than I'd like it to be for compat reasons.

I do like that we added something normative here; I think a server-MAY implies client-MUST-handle, so I don't see the need to have a normative statement on both sides, though I also agree with the original note that it would be nice if that had been more general.  (Servers MAY return the entire file or any set of ranges that contains the bytes the client requested.)  We actually do have a code path, not hit in the common case, where we'll return a larger range than the client asked for.

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz] 
Sent: Saturday, July 25, 2015 1:48 PM
To: ietf-http-wg@w3.org
Subject: Re: Coalescing ranges

On 25/07/2015 10:29 p.m., Mark Nottingham wrote:
> Hi,
> 
> The thing to keep in mind here is that just because the spec says you MAY do something, it doesn't imply that you MUST NOT do other things. I.e., we do not operate under "anything which is not expressly allowed is forbidden" rules. 
> 
> I agree that this could be written a bit more clearly; the normative MAY is somewhat spurious here.
> 

That was to avoid problems like the interpretation we came up with for Squid years back. That the coalescing was not expressly permitted, so we could reject it. That led to problems with some software using Squid and oter clients following the same line of reasoning.

With MAY, we can clearly see that clients need to be able to handle combined ranges back from the server. Clients that don't can have the RFC thrown at their devs.

I was and still am in preference for inverting the requirement so it becomes a "MUST be able to handle" type requirement on client instead of a MAY on servers. But what we have is what was compromised.

Amos

Received on Saturday, 25 July 2015 17:22:41 UTC