Re: XHR setRequestHeader("connection", "close") is bogusly rejected

> As a browser implementor, I don't think I would find this more useful 
> than a boolean property indicating a connection is likely to be long- 
> lived. I can't imagine doing anything more complicated than picking a 
> threshold value to decide whether to count a request towards the 
> connection limit and whether to consider pipelining requests on its 
> connection. If all implementors did this, we'd likely end up with 
> somewhat different threshold values, which would be unfortunate.

We could certainly agree upon and define the threshold values, that is 
trivial. However, would you want the threshold for connection limit counting 
and pipelining to be the same (as a boolean would effectively be)? I would 
think that are some responses that may take a long enough to avoid 
pipelining, but still count in against the connection limit. More 
importantly, pipelining is not simply a yes or no question, it is a question 
of which connection to pipeline on. A faster response is attained by 
pipelining on the connection that will be able handle the request soonest, 
and therefore pipelining becomes a comparison calculation. If browsers have 
numeric values for response time estimates, they can make appropriate 
comparisons and do optimal pipelining.

Perhaps the next iteration of browsers would only be based on thresholds, 
but numeric values allow great transfer of information, which could be used 
for more creative optimizations like pipelining comparisons and perhaps 
optimizations that we haven't even thought of yet. Just because we haven't 
foreseen all the possible optimizations, doesn't mean we shouldn't leave the 
door open for such optimizations. By allowing numeric values, authors can 
begin providing advice, and browsers can use it at their convenience.

Also, as I had mentioned in the proposal, there are situations where authors 
actually want to pipeline requests behind long-lived responses, so they are 
intentially not responded to. Once again, boolean values don't provide an 
adequate mechanism for communicated this desire.

>
> Also, I'm skeptical that authors can estimate request latency with 
> anything near that kind of precision. Thus, it is likely to be an 
> unreliable source of information, meaning that the details of the  value 
> couldn't be trusted anyway, and even a high-low threshold might  be 
> unreliable. But most authors know if their XHR connection is  intended to 
> be used persistently, so the one bit of info would be more  trustworthy.

Sure, it is impossible to create perfectly accurate estimates, and it is in 
fact an estimate and should be treated that way, but it seems very 
presumptious to assume that authors can't provide meaningful data. If 
authors don't know, that can simply not set this property or use a very high 
value to indicate a long-lived response. If they provide errant values, that 
is their problem, but I don't think we should understimate the potential of 
what authors can understand and do.

Thanks,
Kris

Received on Tuesday, 11 March 2008 15:36:05 UTC