Drop connection rather than downloading body for 404s on resource requests

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
7 years ago
3 years ago

People

(Reporter: kats, Unassigned)

Tracking

Trunk
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

This is another thing that came up while I was attending the Velocity conference and talking to some people from Yottaa. Another factor that sometimes comes into play in mobile network performance is when, for examplle, a page has an <img> tag that points to a non-existent image. In this case the browser tries to fetch the image, and instead gets a text/html 404 page from the server, downloads the entire 404 file (which could be sizable) and then throws it away because it cannot render HTML in place of an image. What might be worth investigating is dropping the connection as soon as the headers are received, to avoid the useless data transfer of the resource body.

Comment 1

7 years ago
We would need to add a flag to necko channel IDLs that says "throw 404 away", as it's the layers above necko that know whether we need render the 404 body.

I suspect this might not be such a huge win--by the time we've got the HTTP headers most/all of the body will have arrived too.  Might be a win for large 404 bodies.
When talking to Kats about this, that was the point. We may be paying a fairly steep price for sites that get creative with their 404 pages. This shouldn't be much of a win for a basic 404 page.
Note that dropping the connection also has a cost: you have to establish a new connection.

We should do some measurement to see whether we get useful Content-Length values for these sorts of pages and whether those are worth factoring into the heuristic...
(In reply to Boris Zbarsky (:bz) from comment #3)
> Note that dropping the connection also has a cost: you have to establish a
> new connection.
> 

right.

I'm very skeptical of the proposal because of this.
(In reply to Boris Zbarsky (:bz) from comment #3)
> Note that dropping the connection also has a cost: you have to establish a
> new connection.

Only if there are more transactions that need to be done to the same host. But yes, I agree that this may not end up winning much in practice; we'd have to measure to see how much it helps.
I'm going to wontfix this at the necko layer - the 404 is part of the channel. The channel consumer can cancel the channel if it can't render the content.. which honestly, I suspect it does in most cases, its just that the 404 tends to be fairly short and already delievered.
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.