Otrzymywanie odpowiedzi bezpośrednio z pamięci podręcznej po kliknięciu przycisku powrotu.

Question

Pamiętaj, że nie sądzę, aby ten problem był związany z kręgosłupem lub JavaScript, ale konieczne jest uwzględnienie kodu kręgów jako kontekstu w przypadku problemu.

Kodeks pokrewne

Mam client-side Backbone router z trasy, która przyjmuje parametr o nazwie contactId. Wygląda to mniej więcej tak:

Backbone.Router.extend({ 

    routes: { 
    "jobs/new?contact_id=:contactId": "newForContact" 
    }, 

    // Fetch the contact and initialize a new job model which 
    // is associated with that contact. 
    newForContact: function(contactId) { 
    var contact = new Contact(id: contactId); 
    contact.fetch({ 
     success: _.bind(function(model, resp) { 
     var job = new Job(contact: contact); 
     this.new(job); 
     } 
    }, this)); 
    }, 

    // Show the JobView for the given job. 
    new: function(jobModel) { 
    view = new JobView(job: jobModel); 
    $('body').append(view.render().el); 
    } 
}; 

Teraz staram się korzystać z tej konfiguracji z pushState włączony.

Po uruchomieniu trasy, która wyzwala trasę newForContact, wszystko działa zgodnie z oczekiwaniami. Jeśli jednak w tym momencie naciśnie przycisk wstecz przeglądarki, otrzymam odpowiedź JSON z metody contact.fetch() prosto z pamięci podręcznej przeglądarki. Żadne żądanie nie jest wysyłane na serwer.

App Dzienniki

Można to zobaczyć w szynach dzienników aplikacji. W tej części odwiedzam trasę, która wyzwala newForContact.

Started GET "/jobs/new?contact%5Bid%5D=1&contact%5Btype%5D=Customer" for 127.0.0.1 at 2012-10-31 22:41:48 +0000 
Processing by JobsController#new as HTML 
    Parameters: {"contact"=>{"id"=>"1", "type"=>"Customer"}} 
    User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]] 
    Business Load (0.3ms) SELECT "businesses".* FROM "businesses" WHERE "businesses"."id" IN (1) 
    Rendered shared/_search_form.html.erb (0.3ms) 
    Job Load (0.4ms) SELECT "jobs".* FROM "jobs" WHERE "jobs"."business_id" = 1 ORDER BY created_at desc 
    Rendered jobs/_list.html.erb (1.5ms) 
    Rendered jobs/index.html.erb within layouts/application (4.1ms) 
    Rendered layouts/_head_content.html.erb (0.7ms) 
    Rendered layouts/_flash.html.erb (0.0ms) 
Cache read: views/jobs/main_nav/d6a805d9b6f285e424f207add4f35595 
Read fragment views/jobs/main_nav/d6a805d9b6f285e424f207add4f35595 (0.4ms) 
    Rendered layouts/_nav.html.erb (0.6ms) 
    Rendered layouts/_header.html.erb (0.7ms) 
Completed 200 OK in 12ms (Views: 8.0ms | ActiveRecord: 1.0ms) 
Cache read: http://print.dev/customers/1? 

Można zobaczyć, że pobiera kontakt w tym momencie za pomocą żądania JSON.

Started GET "/customers/1" for 127.0.0.1 at 2012-10-31 22:41:48 +0000 
Processing by CustomersController#show as JSON 
    Parameters: {"id"=>"1"} 
    User Load (0.5ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 1]] 
    Business Load (0.4ms) SELECT "businesses".* FROM "businesses" WHERE "businesses"."id" IN (1) 
    Customer Load (0.2ms) SELECT "customers".* FROM "customers" WHERE "customers"."business_id" = 1 AND "customers"."id" = $1 LIMIT 1 [["id", "1"]] 
    CustomerEmployee Load (0.3ms) SELECT "customer_employees".* FROM "customer_employees" WHERE "customer_employees"."employer_id" IN (1) 
    Job Load (0.4ms) SELECT "jobs".* FROM "jobs" WHERE "jobs"."contact_type" = 'Customer' AND "jobs"."contact_id" IN (1) 
    Invoice Load (0.3ms) SELECT "invoices".* FROM "invoices" WHERE "invoices"."client_id" IN (1) 
    Job Load (0.5ms) SELECT "jobs".* FROM "jobs" WHERE "jobs"."contact_id" = 1 AND "jobs"."contact_type" = 'Customer' AND "jobs"."state" = 'finished' AND "jobs"."invoice_id" IS NULL 
    Rendered customers/show.json.rabl (2.8ms) 
Completed 200 OK in 67ms (Views: 3.2ms | ActiveRecord: 2.5ms) 

W tym miejscu naciskałbym przycisk powrotu przeglądarki, ale na serwerze nie zarejestrowano nowego żądania.

Szyny Środowiska

Dzieje się tak tylko na moim serwerze pomostowym (Heroku), a nie w fazie rozwoju. Mogę go odtworzyć lokalnie, uruchamiając aplikację z Pow w środowisku pomostowym, w którym włączone jest buforowanie w konfiguracjach szyn.

config.action_controller.perform_caching = true 

Zauważ, że nawet z buforowania włączone, nie mogę odtworzyć błąd w środowisku programistycznym.

Ten problem występuje w następujących wersjach: Chrome 22.0.1229.94, FF 16.0.2 i Safari 6.0.1. Używam Railsów 3.2.8.

Ewentualnie Podobne pytania

It seems like this guy was having a very similar problem to me.

żywo Próbka

Jeśli naprawdę chcesz, aby można obejrzeć na żywo na problem mojego serwera pomostowego na Heroku.

Kroki prowadzące do repro (edycja: te nie działają dłużej, ponieważ naprawiłem problem).

1. Zaloguj here z e-mail: user@example.com i hasło: foobar
2. Odwiedź http://print-staging.herokuapp.com/customers/2. Powinieneś zobaczyć otwarte okno dialogowe z pomieszaniem.
3. Kliknij małe łącze "Nowa praca" w oknie dialogowym. Strona powinna się zmienić i otworzyć nowe okno dialogowe.
4. Kliknij przycisk wstecz przeglądarki.

Answer 1

Możesz dodać nagłówek no-cache do odpowiedzi na stronie serwera, to powinien nakazać przeglądarce nie buforować odpowiedzi:

response.headers["Cache-Control"] = "no-cache" 

Answer 2

nie używam kręgosłup, to jest tylko to, co mam zrobić z AJAX/pushState

---

history.pushState() używam w moich odpowiedziach AJAX.

var url = "http://foo.com/path/to/page"; 
var relative_url = UrlToRelative(url); // some function to convert a URL to relative 
var absolute_url = UrlToAbsolute(url); // some function to convert a URL to absolute 
history.pushState(
    { 
    hash: "#"+relative_url, 
    title: document.title, 
    initialHref: absolute_url 
    }, 
    document.title, 
    url 
); 

I mam detektor zdarzeń dla onPopState:

window.onpopstate = function(event) { 
    if (event.state && event.state.initialHref) { 
    $.ajax({ 
     complete: null, 
     data: {}, 
     dataType: "script", 
     success: null, 
     type: 'GET', 
     url: event.state.initialHref 
    }); 
    } 
} 

Ten detektor zdarzeń sprawia, że ​​żądania AJAX. Jedynym problemem jest to, że zmiana ekranu następuje po kilku sekundach, gdy wracamy do stron, które wymagają kilku sekund, aby uzyskać odpowiedź serwera. I nie ma wskaźnika postępu przędzarki ani zajętości.