Turning off caching on /api/ endpoints w/ CORS #220

Closed
tmcw opened this Issue Mar 25, 2013 · 3 comments

Projects

None yet

2 participants

@tmcw
Member
tmcw commented Mar 25, 2013

Right now some calls w/ oauth credentials are cached by the rails port and get a 304 response: confirm by logging in to

Specific call: http://www.openstreetmap.org/api/0.6/user/details

The latter will get a 304 error until you clear your browser cache and you no longer send any cache-related headers.

Do we want caching on the endpoints? It's not clear how to fix this issue - have multiple web-based OAuth clients without conflicts - just from the JS side.

@tmcw tmcw referenced this issue in osmlab/osm-auth Mar 25, 2013
Closed

Break or tolerate 304s #1

@tomhughes
Member

They're not "cached by the rails port" but rather your browser has cached it and sends an If-None-Match asking if it is still the same and we say "yes it is" because the hash hasn't changed.

Why is this a problem? We've said it hasn't changed, and it hasn't, so the browsers cached copy is fine?

@tomhughes
Member

So the problem is that the browser makes a CORS enabled request to the API with Origin: a and the response has an ETag value and is marked as privately cacheable and dependent on the origin (Vary: Origin) and has Access-Control-Allow-Origin: a to match the request.

When the browser makes the second request it sees the Vary: Origin and tries to revalidate using the new Origin: b header and the server says 304 nothing changed here but the browser reuses the old cached Access-Control-Allow-Origin rather than the new one the server sent for the new origin.

@tomhughes
Member

I've applied d53bbe5 to disable caching for CORS responses, which should fix the problem although it's rather ugly and I'm not at all clear that there shouldn't be a better solution...

The interesting thing is that the 304 response doesn't actually carry the CORS response headers so the browser couldn't use them even if wanted to. They are getting returned from the ruby part of passenger to the C part though, and I don't think the C part is eating them, so I think the apache core must be discarding them for some reason.

In any case I have been unable to find any discussion anywhere of how CORS and caching and conditional gets are supposed to interact so I really don't know what should be happening here.

@tomhughes tomhughes closed this Mar 25, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment