HTTP Caching is broken on webcompat.com

[karlcow]

We must have made a modification at a point which has broken our cache. We need to figure it out :)
So far just a preview. I tried to navigate a bit more and I get only "200" except for github and google which are sending the right things for their own parts independent of webcompat.

Let's try with 773

• html /issues/773 No Etag sent by the server, no caching information.
  So the second time we hit it it does the same thing again.

Hmm… I wonder if we butchered all of that when we decided to put under https?

[miketaylr]

Yep, only CSS is cached on re-loads for me. That's busted.

[miketaylr]

OK, so that's not necessarily true. Re-testing again I get 304s except for 779.json. We should be able to fix that.

[miketaylr]

It looks like the source of the bug is we only do conditional GET for logged in users. If I log in, I get a 304 on 779.json on the 2nd time.

So the fix would be to incorporate get_request_headers into proxy_request.

[miketaylr]

OK in theory that's supposed to be happening here: https://github.com/webcompat/webcompat.com/blob/master/webcompat/issues.py#L31

[miketaylr]

Ah, I think I see the bug. headers is not the headers we think it is. :)

[karlcow]

@miketaylr did a good job for the JSON part. We need to fix the caching story for HTML too.
I have opened #609