Unofficial parts once again being redirected to https


RE: Unofficial parts once again being redirected to https
#17
(2024-01-29, 4:23)Travis Cobbs Wrote: It seems that though Last-Modified is being sent, passing it back to the server in the If-Modified-Since request header isn't working (This worked before you changed servers.) The new server is sending a 200 OK response with the file data instead of a 304 Not Modified response.

Concrete example: when I request unofficial part 2676.dat, the response header contains "Last-Modified: 2023-08-07 18:57:57". When I request the file again with "If-Modified-Since: 2023-08-07 18:57:57" in the request header, I get the whole file back, with the same Last-Modified date.

Possibly related: the old server had a different date/time format for its Last-Modified value, and the format that new server is using appears to not follow the http spec. The example given in the spec looks like this: "Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT". Since If-Modified-Since also technically requires dates to be in the same format, it could be that the bad date format in Last-Modified is causing If-Modified-Since not to work. Note that these two headers very intentionally use the same format so that a program only has to store the string value for reuse, and isn't required to parse the date in order for the mechanism to work.

The "If-Modified-Since" response likely hasn't existed since we switched to the new PT software. I've, hopefully, added it back in and corrected the malformed date format.
Reply
« Next Oldest | Next Newest »



Messages In This Thread
RE: Unofficial parts once again being redirected to https - by Orion Pobursky - 2024-01-29, 20:37

Forum Jump:


Users browsing this thread: 3 Guest(s)