Content-Negotiation ignoriert, wenn Browser Zurück-Taste

Question

Hier ist die Situation:

Ich habe eine Web-Anwendung, die Antwort auf eine Anfrage für eine Liste von Ressourcen, sagen kann:

/items

Dies wird zunächst direkt vom Web-Browser angefordert durch zu diesem Pfad zu navigieren. Der Browser verwendet, es ist Standard „Accept“ Header, die „text / html“ und meine Anwendung bemerkt dies und gibt den HTML-Inhalt für die Artikelliste enthält.

Im zurück HTML ist einige JavaScript (jQuery), die dann tut eine Ajax-Anfrage die aktuellen Daten abzurufen:

/items

Nur dieses Mal wird die „Accept“ Header „application / json“ explizit festgelegt. Auch hier merkt meine Anwendung dieses und JSON korrekt auf die Anforderung zurückgegeben, werden die Daten in die Seite eingefügt, und alles ist glücklich.

Hier kommt das Problem : Der Benutzer navigiert zu einer anderen Seite, und später drückt die BACK-Taste. Sie werden dann aufgefordert, eine Datei zu speichern. Dies erweist sich als die JSON Daten der Artikelliste.

Bisher habe ich bestätigt, dass es sowohl in Google Chrome und Firefox 3.5 geschehen.

Es gibt zwei mögliche Arten von Antworten hier:

1. Wie kann ich das Problem beheben. ist es einige magische Kombination von Cache-Control-Header oder andere Voodoo, die den Browser zu tun das Richtige hier?

2. Wenn Sie denken, ich etwas tue schrecklich falsch hier, wie soll ich gehen über das? Ich suche Korrektheit, sondern auch versuchen, nicht zu opfern Flexibilität.

Wenn es hilft, ist die Anwendung eine JAX-RS Web-Anwendung, mit Restlet 2.0m4. Ich kann Probe Request / Response-Header zur Verfügung stellen, wenn es nützlich ist, aber ich glaube, das Problem vollständig reproduzierbar ist.

Answer 1

  

Gibt es eine magische Kombination von Cache-Control-Header oder andere Voodoo, die der Browser hier das Richtige zu tun?

Wenn Sie unterschiedliche Reaktionen auf verschiedene dienen akzeptieren: Header, müssen Sie den Header enthalten:

Vary: Accept

in Ihrer Antwort. Der Header Vary sollten auch alle anderen Request-Header enthalten, dass Einfluss auf die Antwort, so zum Beispiel, wenn Sie gzip tun / abzulassen Kompression Sie Accept-Encoding umfassen müssen.

IE leider viele Werte von Vary Griffe schlecht, vollständig zu brechen Cachen, die Sie vielleicht oder Materie vielleicht nicht.

  

Wenn Sie denken, ich etwas schrecklich falsch hier tue, wie soll ich über diese gehen?

Das glaube ich nicht die Idee von unterschiedlichen Inhalten für verschiedene Arten mit der gleichen URL dient schrecklich falsch ist, aber Sie lassen sich für mehr Kompatibilitätsprobleme in als Sie wirklich brauchen. Unter Berufung auf Header durch JSON Arbeit ist nicht wirklich eine gute Idee in der Praxis; Sie würden am besten dran, eine andere URL nur mit, wie /items/json oder /items?format=json.

Answer 2

Ich weiß, diese Frage ist alt, aber nur für den Fall, dass jemand andere läuft in diesen:

Ich hatte das gleiche Problem mit einer Rails-Anwendung mit jQuery, und ich regelte es durch den Browser nicht zu sagen, die JSON-Antwort mit der Lösung hier auf eine andere Frage gegeben zwischenzuspeichern:

jQuery $. getJSON funktioniert nur einmal für jede Kontrolle. Nicht erreicht der Server wieder

Das Problem schien nur mit Chrome und Firefox auftreten. Safari wurde Umgang mit dem Rücken Verhalten in Ordnung, ohne es explizit zu nicht-Cache zu sagen zu haben.

Answer 3

Alte Frage, aber für alle anderen das sehen, es ist nichts falsch mit der Nutzung des Fragestellers des Accept-Header.

Dies ist ein bestätigter Fehler in Chrome. (Früher auch in Firefox aber da festgelegt.)

http://code.google.com/p/chromium/ Fragen / detail? id = 94369