better ETag for Departures.csv would reduce bandwidth

[Eric Slosser]

To minimize bandwidth, my requests to http://developer.mbta.com/lib/gtrtfs/Departures.csv use the "If-None-Match" header, setting it to value in the "Etag" header from a previous response.

What I notice is that after the Etag changes, the next 4 responses will have a 304 status, then the ETag changes again.

In my cursory testing I find that, 7 out of 8 times, a change in Etag is NOT accompanied by any change in the response body.  

This is technically legit, because the Etag is of the format W/"123456789".  An examination of the responses' other header fields suggests that the "Date" and "Last-Modified" fields are changing every 5 seconds.

Wouldn't it make sense to use the strict form of the Etag, and only send the body of the file when it changes?

This is different from the situation reported a few days ago by James Synge in which a strict Etag is returned but (I think) different servers are using different Etag values for the same content.

https://groups.google.com/d/topic/massdotdevelopers/0-YvqxRtDs0/discussion

[James Synge]

I noticed a similar behavior and reported it in the past. It appears there are several servers each with their own filesystem, the updates aren't simultaneous, nor do they force the file timestamps to be the same. Furthermore, I believe they are using iis as their server, and it computers etags from filesystem metadata, not from the contents of the file.

--
You received this message because you are subscribed to the Google Groups "MBTA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to massdotdevelop...@googlegroups.com.
To post to this group, send email to massdotd...@googlegroups.com.
Visit this group at https://groups.google.com/group/massdotdevelopers.
For more options, visit https://groups.google.com/d/optout.

[Ken Yee]

I wish they'd just add the platform info for commuter rail trains in their regular Realtime V2 API :-P