Change Details

In T238849#5683035, @ssastry said that VE sends weak eTags in If-Match headers, which is a bug per [[https://datatracker.ietf.org/doc/html/rfc7232#section-3.1|the HTTP spec]], which sais that //"An origin server MUST use the strong comparison function when comparing entity-tags for If-Match"//. To work around this, the ParsoidHandler base class disables conditional header handling - which isn't great, and we don't want to do this for core's page/{title}/html endpoint. The simples solution would be for VE to send strong eTags with If-Match (for If-None-Match, weak eTags are acceptable, though I'm not sure whether it would be correct here). See (somewhat outdated) T303370 for the parsoid part of things. The relevant code on the server side is ParsoidHandler::checkPreconditions. It should ideally be deleted, to restore the default behavior.

ParsoidHandler currently overrides checkPreconditions() to disable HTTP conditionals such as If-Match and If-Non-Match. This method should be deleted to restore the default behavior. However, we cannot currently start using If-Match headers, since Visual Editor presently sends "weak" eTags, which per [[https://datatracker.ietf.org/doc/html/rfc7232#section-3.1|the HTTP spec]] will never match If-Match (they are for use with If-None-Match only). See @ssastry on T238849#5683035. The reaon is that VE is receiving a weak eTag when it loads the page's HTTP. The weak etag is produced by the parsoid page endpoint in RESTbase. This is incorrect: if we want to be able to use the eTag to protect a modifying operation such as an edit, it must be a strong etag. Even for reading, we want the client to get fresh data when the rendering of the page changes in any way. This issue may resolve itself when VE startes to read data from the core endpoints, v1/page/{title}/html and v1/revision/{id}/html. These endpoints return strong eTags. == Context == # If-Match and If-None-Match serve very different purposes: If-None-Match is the modern version of If-Modified-Since, and can be used in GET requests to only load a resource if a (significant) update is available. If-Match however is used to protect PUT/POST/DELETE requests with check-and-set semantics: it means the server will nto perform the requested action on the resource if it is no longer exactly the resource that the client was aware of. # A client should never generate or modify an etag. The etag always comes from the etag header of an HTTP response from the server, and is sent back to that same server later. # An eTag cannot be converted between weak and strong. Whether it is weak or strong is inherent in the way the tag is computed: it either guarantees byte-by-byte equality, or it doesn't. If it doesn't, it is interpreted to represent semantic equivalence in the intended usae context of the resources. # See (somewhat outdated) T303370 for the parsoid part of things.

In T238849#5683035, @ssastry said that VE sends weak eTags in If-Match headers, which is a bug per [[https://datatracker.ietf.org/doc/html/rfc7232#section-3.1|the HTTP spec]],ParsoidHandler currently overrides checkPreconditions() to disable HTTP conditionals such as If-Match and If-Non-Match. which sais that //"An origin server MUST use the strong comparison function when comparing entity-tags for If-Match"//This method should be deleted to restore the default behavior. To work around thisHowever, the ParsoidHandler base class disables conditional header handlwe cannot currently start using - which isn't greatIf-Match headers, and we don't want to do this for core's page/{title}/html endpoint.since Visual Editor presently sends "weak" eTags, The simples solution would be for VE to send strong eTags with If-Match (for If-None-Match, weak eTags are acceptable,which per [[https://datatracker.ietf.org/doc/html/rfc7232#section-3.1|the HTTP spec]] will never match If-Match (they are for use with If-None-Match only). though I'm not sure whether it would be correct here)See @ssastry on T238849#5683035. See (somewhat outdated) T303370 for the parsoid part of thingsThe reaon is that VE is receiving a weak eTag when it loads the page's HTTP. The weak etag is produced by the parsoid page endpoint in RESTbase. This is incorrect: if we want to be able to use the eTag to protect a modifying operation such as an edit, it must be a strong etag. Even for reading, we want the client to get fresh data when the rendering of the page changes in any way. The relevant code on the server side is ParsoidHandler::checkPreconditionsThis issue may resolve itself when VE startes to read data from the core endpoints, v1/page/{title}/html and v1/revision/{id}/html. These endpoints return strong eTags. == Context == # If-Match and If-None-Match serve very different purposes: If-None-Match is the modern version of If-Modified-Since, and can be used in GET requests to only load a resource if a (significant) update is available. If-Match however is used to protect PUT/POST/DELETE requests with check-and-set semantics: it means the server will nto perform the requested action on the resource if it is no longer exactly the resource that the client was aware of. # A client should never generate or modify an etag. The etag always comes from the etag header of an HTTP response from the server, and is sent back to that same server later. # An eTag cannot be converted between weak and strong. Whether it is weak or strong is inherent in the way the tag is computed: it either guarantees byte-by-byte equality, or it doesn't. It should ideally be deletedIf it doesn't, to restore the default behaviorit is interpreted to represent semantic equivalence in the intended usae context of the resources. # See (somewhat outdated) T303370 for the parsoid part of things.