The patch in bug 599164 disables pipelines for XHR transactions.. Long polls are one of the major pipeline interaction problems, so that is sensible. OTOH there certainly are things done from XHR that fit the pipeline pattern well. So we should provide a hint that JS authors can use to tell the HTTP engine that all the resources are "fast" in a pipelineable sense. I think there are a bunch of different ways to do this so I have split this patch out from 599164 so as not to block that work.
This is one approach to the problem. Allow XHR (or any channel user) to do this: httpRequest.setRequestHeader('X-UA-Response-Speed', 'fast') which bypasses the SLOW indicator that is placed on by default for XHR. It avoids changing IDLs, prefixes, detection code, etc.. if it is executed in a context that doesn't understand it the result is a harmless nop.
bitrot and styl updates..
IMO, a request header is not great. It makes every request bigger. The disadvantages of an API call mentioned above seem small. An API call as a hint also seems to fit better with HTML rel mechanism that mnot suggested in his pipelining hints draft.
update bitrot to reflect larch
Comment on attachment 542082 [details] [diff] [review] Allow X-UA-Response-Speed: fast to bypass SLOW heuristic Dropping the review request for now, just because I'm cleaning my review queue, before we get to the pipelining stuff again. Let's discuss this particular feature more widely first.
During discussion of how to optimize our addons update check, I suggested that we may be able to add a hint to cause Necko to be optimistic about pipelining for a connection to reduce the number of parallel connections to versioncheck.addons.mozilla.org during update checking. If the addon update checker uses XHR (probably) then having such an option might be part of solving that problem.
if anything - we will rip out pipelines
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.