Page MenuHomePhabricator

MediaWiki should check ETags
Closed, DeclinedPublic

Description

Currently MediaWiki checks the If-Modified-Since header and sends a 304 response if, indeed, the resource has not been modified since. However, no such check is done for ETags, even despite the fact that the ETag header can be enabled with the $wgUseETag configuration variable.

MediaWiki should check the If-None-Match header and respond appropriately.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz47529

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:28 AM
bzimport set Reference to bz47529.
bzimport added a subscriber: Unknown Object (MLST).

Related URL: https://gerrit.wikimedia.org/r/60440 (Gerrit Change I02d25e8bc6bd2231fb813f7c9f7118d8a7539b11)

What is the point in doing this? It's not required by the spec. Does it have some performance advantage?

Changing to enhancement.

(In reply to comment #3)

What is the point in doing this? It's not required by the spec. Does it have
some performance advantage?

Not AFAIK. Although one thing it does allow is multiple cached versions of the page, i.e., if the browser has multiple cached versions it can send the ETag of each one, and if any of them matches the server will respond with 304. If-Modified-Since doesn't support this since it is just given one date value.

(In reply to comment #4)

Changing to enhancement.

(In reply to comment #3)

What is the point in doing this? It's not required by the spec. Does it have
some performance advantage?

Not AFAIK. Although one thing it does allow is multiple cached versions of
the page, i.e., if the browser has multiple cached versions it can send the
ETag of each one, and if any of them matches the server will respond with 304.
If-Modified-Since doesn't support this since it is just given one date value.

Is there any browser that does that?

(In reply to comment #5)

Is there any browser that does that?

I don't know, but is there any harm in supporting it? I'm not saying this is high priority or anything, but nonetheless it's something we can do.

It's a fairly complex change to review. It's easy to imagine ways in which adding ETag support could break things. The code is difficult to test due to the lack of client support, and could easily be broken by future updates to caching semantics in other parts of MediaWiki. In exchange for time spent reviewing it, and the inevitable time which will be required to maintain it in the future, I would like there to be some kind of benefit.

Potential rationale in bug 32364

Tgr set Security to None.
Krinkle claimed this task.
Krinkle edited projects, added Performance-Team; removed Patch-For-Review.
Krinkle subscribed.
@Krinkle merged in Gerrit (June 2016):

[mediawiki/core] Remove incomplete and dated wgUseETag experiment.

Follows-up:

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/296221