On 12/12/20 12:59 AM, Roy T. Fielding wrote:
>> On Dec 11, 2020, at 6:28 AM, Ruediger Pluem <rpl...@apache.org 
>> <mailto:rpl...@apache.org>> wrote:
>> On 12/11/20 1:13 PM, Yann Ylavic wrote:
>>> On Fri, Dec 11, 2020 at 12:49 PM Graham Leggett <minf...@sharp.fm 
>>> <mailto:minf...@sharp.fm>> wrote:
>>>> On 10 Dec 2020, at 18:04, yla...@apache.org <mailto:yla...@apache.org> 
>>>> wrote:

>> Old RFC2616 SectionNew RFC and sectionLink
>> 14.9.4RFC7234,
>> 10.5.3RFC7231, 6.6.3https://tools.ietf.org/html/rfc7231#section-6.6.3
>> 10.5.5RFC7231, 6.6.5https://tools.ietf.org/html/rfc7231#section-6.6.5
> Heh, sorry, the current version is
> https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#cache-response-directive.must-revalidate
> https://httpwg.org/http-core/draft-ietf-httpbis-cache-latest.html#rfc.section.4.3.3
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#status.502
> and we have until Monday to fix it, if needed.
>> After rereading the sections on the new RFC's my opinion is still the same 
>> as in
>> https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa%401367999236%40%3Cdev.httpd.apache.org%3E
>> <https://lists.apache.org/thread.html/be0e7bdc3510fddd2dd80accece44917eba361ef4fcc713dd0f7f7fa@1367999236@<dev.httpd.apache.org>>
>> IMHO RFC7231, 6.6.3 and RFC7231, 6.6.5 apply for the proxy/gateway. In the 
>> revalidate case (RFC7234, the issue for the
>> cache may be even wider: What if the reply on the revalidation request from 
>> the backend is not cachable for whatever reason (like
>> the 502 here without appropriate headers that allow caching)?
>> Does the cache just pass the reply on and does not update its cache? Does it 
>> remove the stale entry from the cache?
>> Apart from this the proxy could add a note to r->notes if there was a 
>> network issue with the backend such that the cache can reply
>> with 504 in this case. But of course this only helps in the case that the 
>> next hop was not reachable. If the 502 is created by a
>> further gateway between us and the origin server the issue remains.
> That is too many questions. The purpose of the cache requirement is so that 
> the cache
> does not deliver a non-validated entry after receiving a failed validation. 
> It doesn't really
> matter what code is returned so long as it is 5xx, so the specs are 
> over-constraining here.
> The CoAdvisor test suite is overly pedantic.
> And, as stated, this only applies when the request contains max-revalidate 
> and the
> action being done is a cache revalidation. No other code should behave this 
> way.
>>> You should do that, it's not my veto. Failing to resolve the
>>> discussion, the commit should be reverted right?
>>>> The last on the thread is that Roy was asked for advice, but he was busy. 
>>>> In the light of RFC7230 it would be useful to get a
>>>> new answer on this question.
>>> Sure.
>> Can you please help us resolving this Roy?
> Reverting the change is the correct call, regardless, but it is also the 
> right choice.
> I have filed a bug on the Cache spec to change that MUST send 504 to a MUST 
> send 5xx.
>    https://github.com/httpwg/http-core/issues/608

Thanks for the clarification and for creating the issue to the spec.



Reply via email to