User Details
- User Since
- Oct 10 2014, 8:08 AM (402 w, 5 d)
- Availability
- Available
- IRC Nick
- dues, duesen
- LDAP User
- Daniel Kinzler
- MediaWiki User
- DKinzler (WMF) [ Global Accounts ]
Today
Yesterday
Further, we could have a "quirk" setting in the REST framework that allows weak etags to match in an If-Match header for specific endpoints.
Mon, Jun 27
Similar task: T203481: Use a mock clock in unit tests
Wed, Jun 22
Tue, Jun 21
RunJobs.php has been deleted
Fri, Jun 17
Pinging @BBlack and @Vgutierrez in the hope they can shed some light...
So let me see if I'm getting this right: VE gets HTML via Varnish and RESTbase. It's getting an ETag generated by RESTbase, and "weakened" by Varnish.
Thu, Jun 16
On Slack, @Arlolra pointed out that it may be Varnish adding the W/ prefix to "weaken" the etag. Per the varnish docs, this might indeed be the case: https://varnish-cache.org/docs/6.0/users-guide/compression.html
The issue originates in I5edfa8aa54dedaec418579bbef37aa040170d09b, which sais: ETag harmonisation Add custom weak ETag to page requests in the format used by RESTBase.
The issue originates in I5edfa8aa54dedaec418579bbef37aa040170d09b, which sais: ETag harmonisation Add custom weak ETag to page requests in the format used by RESTBase.
Wed, Jun 15
But, once Parsoid is integrated into core and with ParserCache, and when HTML stashing is implemented for VE (similar to how it is done in RESTBase), the etag will come from this stashed entry.