Buforowanie HTTP z autoryzacją

Question

Biorąc pod uwagę odpowiedź serwera WWW, który zawiera nagłówek Authorization zgodnie ze specyfikacją OAuth, buforowanie HTTP nie przydaje się?

W tym przypadku buforowanie HTTP drugie żądanie zwróci buforowaną odpowiedź dla pierwszego użytkownika. Nie stanowi to problemu dla treści, które są ogólne dla wszystkich użytkowników, ale dla udostępnianej pamięci podręcznej udzielanie odpowiedzi innym użytkownikom jest niewłaściwe.

Podobnie, jeśli użyjemy nagłówka Vary i zmieni się on o Authorization, oznacza to, że nasza pamięć podręczna będzie przechowywać buforowaną kopię na token, który z pewnością pokonuje cel buforowania HTTP. Lokalna pamięć podręczna przeglądarek (prywatna) działałaby dobrze, ale nadal oznaczałoby to żądanie od każdego użytkownika co najmniej raz na sesję.

Edit

Obsługa w kwestii wymaga autoryzacji dla wszystkich żądań, jednak na podstawie tego co czytałem, służąc odpowiedzi ze wspólnej pamięci podręcznej, które zawierają nagłówki autoryzacji nie powinny być wykonywane, chyba że koniecznie trzeba revalidate, publiczny i s-maxage są obecne.

Moje pytanie brzmi więc, że biorąc pod uwagę API, które ma zarówno ogólne (odpowiedzi takie same dla wszystkich użytkowników), jak i odpowiedzi specyficzne dla użytkownika, buforowanie jest możliwe? Posiadanie s-maxage i publicznych nagłówków, ale nagłówek autoryzacji oznacza, że ​​pamięć podręczna rozwiąże odpowiedź UserA na UserB, UserC i tak dalej, jeśli poprawnie podążam za RFC.

Answer 1

Zobacz http://greenbytes.de/tech/webdav/rfc7234.html#response.cacheability:

„cache NIE przechowywać odpowiedź na każde żądanie, chyba że: Metoda żądania jest rozumiane przez cache i zdefiniowane jako buforowalny i ... pole nagłówka Authorization (patrz sekcja 4.2 [RFC7235]) nie pojawia się w żądaniu, ... "