Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending Vary header for AJAX requests. #1133

Closed
hrach opened this issue Jun 7, 2013 · 14 comments
Closed

Sending Vary header for AJAX requests. #1133

hrach opened this issue Jun 7, 2013 · 14 comments

Comments

@hrach
Copy link
Contributor

hrach commented Jun 7, 2013

  • Browsers cache the content.
  • The cache key is based on URL and other headers defined in Vary header
  • Nette send different content for the same URL, detection is done by XHttpRequestWith header.

We must add Vary header, which tells the browser that the cache should depend on XHttpRequestWith header.

vojtech-dobes/nette.ajax.js@07f03cc

Related bug in Firefox (months ago fixed): https://bugzilla.mozilla.org/show_bug.cgi?id=633743

@vojtech-dobes
Copy link
Contributor

👍

@dg
Copy link
Member

dg commented Jun 10, 2013

@hrach
Copy link
Contributor Author

hrach commented Jun 10, 2013

The problem was connected with reverting closed tab. I can imagine, that in this use-case it ignore expire header. @vojtech-dobes what was the reason for you workaroung? was it a problem only in Fx?

@vojtech-dobes
Copy link
Contributor

It also happened when navigating Back, eg. I click on link to another
website, then click Back, and see the raw JSON response. I can test it in
Chrome, but my personal experienced is few days old from Firefox.

@dg
Copy link
Member

dg commented Jun 10, 2013

The question is where send Vary header. In Presenter::sendPayload()?

@vojtech-dobes
Copy link
Contributor

I guess that would be ideal. It seems to me fine to leave using of that header to developer's good judgement if he doesn't use payload.

@fprochazka
Copy link
Contributor

I would say more like the json response? It feels more right in there.

@hrach
Copy link
Contributor Author

hrach commented Dec 15, 2013

Vary header should be send everytime, when the url serving different contents because of some header. This has nothing to do with sendJson (or json response), action could return json everytime, no need to send vary header. In general, this is about nette approach with snippets & ajax, so it should be send everytime we render template with snippets.

@mishak87
Copy link
Contributor

Nette should send Vary always as per RFC

An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation.

Pulling snippet information from rendered template or detection if some code path is using ajax would require hacking probably with some ob_start(). What about adding config nette.response.vary = off (default: X-Requested-With, Cookie, Accept-Encoding) or something like that that would send it always.

Or maybe adding configurable headers using nette.response.headers.X-Powered-By: off (default: Nette Framework) would solve this as a feature since some fixed headers are generated by NetteExtension anyway and there is no way to turn them off.

@dg
Copy link
Member

dg commented Dec 18, 2013

added nette.http.headers f59f3b1

@hrach
Copy link
Contributor Author

hrach commented Dec 18, 2013

Well, the added api is nice, but seem to be quite unrelated to this bug, doesn't it?

@dg
Copy link
Member

dg commented Dec 19, 2013

This can not be solved automatically because when we render page we don't know if it contains a snippet. It may be inside the component.

What about send Vary header always by UI\Presenter?. Unwanted side effect is minimal and it solves the problem.

    public function run(Application\Request $request)
    {
        ... 

        if (!$this->httpResponse->isSent()) {
            $this->httpResponse->addHeader('Vary', 'X-Requested-With');
        }

@hrach
Copy link
Contributor Author

hrach commented Dec 19, 2013

Yes, agreed!

@vojtech-dobes
Copy link
Contributor

Perfect, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants