Opened 4 years ago

Last modified 4 years ago

#1564 new defect

I2P console responds 304 Not Modified (Console pages does not gets updated)

Reported by: DjJeshk Owned by:
Priority: major Milestone: undecided
Component: apps/console Version: 0.9.19
Keywords: cache not modified 304 Cc:
Parent Tickets: Sensitive: no

Description

I2P version: 0.9.19-17
Java version: Oracle Corporation 1.8.0_45 (Java™ SE Runtime Environment 1.8.0_45-b14)
Wrapper version: 3.5.25
Server version: 8.1.17.v20150415
Servlet version: Jasper JSP 2.1 Engine
Platform: Windows 7 x86 6.1
Processor: Core 2 (45nm) (core2)
Jbigi: Locally optimized library jbigi-windows-core2.dll loaded from file
Encoding: Cp1257
Charset: windows-1257

Symptom:
I upgraded to -17 successfully, left console open, and after some minutes it shows cached version with -16 and console does not updates at all.

Cause:
If browser does not send Keep-Alive, JSESSIONID cookie nor no-cache, then it responds 304 Not Modified.

See IE11 network monitor screenshots.

I saw this too in Firefox, but it does hide its fault if network monitor is opened (press F12 to open in your browser).

Subtickets

Attachments (2)

i2p304_1.png (189.2 KB) - added by DjJeshk 4 years ago.
proof of 304 responses
i2p304_2.png (360.7 KB) - added by DjJeshk 4 years ago.
304 on main console

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by DjJeshk

Attachment: i2p304_1.png added

proof of 304 responses

comment:1 Changed 4 years ago by zzz

Status: newinfoneeded_new

please specify URLs that are returning 304

comment:2 Changed 4 years ago by zzz

ok, just missed seeing the attachment.
which 304's are a problem?

comment:3 Changed 4 years ago by DjJeshk

Status: infoneeded_newnew

everything which starts with /xdr1.jsp? and probably all console pages because I am able to navigate back and see outdated cached version.

Version 0, edited 4 years ago by DjJeshk (next)

comment:4 Changed 4 years ago by DjJeshk

I can confirm - every page is affected. I will add additional attachments.

Last edited 4 years ago by DjJeshk (previous) (diff)

Changed 4 years ago by DjJeshk

Attachment: i2p304_2.png added

304 on main console

comment:5 Changed 4 years ago by DjJeshk

Summary: I2P console responds 304 Not ModifiedI2P console responds 304 Not Modified (Console pages does not gets updated)

comment:6 Changed 4 years ago by zzz

304 for flags, icons, images, and css are expected and normal, as we set a Cache-Control header for those. So let's ignore all of that.

For pages such as /console, 304 is not expected. We don't set a Cache-Control header, and there is no header in the screenshot. But there's also no If-Modified-Since or If-None-Match header in the request. You should never get a 304 back unless you included a conditional header in the request? Not sure. See RFC 2616. This may be an IE thing, or the IE network monitor is not telling the truth or is synthesizing a network action when it's really pulling from local cache (and you imply the same thing happens in Firefox in the OP: "it does hide its fault if network monitor is opened")

We may need to attempt to reproduce this with wget, eepget, or similar, to eliminate network monitor lies and browser caches.

But also need to research allowed caching if no Cache-Control header is set.

comment:7 Changed 4 years ago by zzz

OK I skimmed RFC 2616. Caching is allowed by default.

I see that Jetty sends the Expires header if there's no session (confirmed with eepget) but does not if there's a session.

We removed the cache directives in css.jsi in March 2011 because they were causing reloads of POSTed fetches when the user clicked the back button (since we don't do P-R-G). Perhaps we can come up with some combination of headers that will work.

I still suspect that the 304s shown in the screenshot are 'fake', it's just pulling from browser cache?

Note: See TracTickets for help on using tickets.