Topic: 304 Error handling

Cozi has developed a calendar Widget for www.cozi.com.

When we poll for new appointments, we pass a 'version' number in the query string to indicate the version of the appointments we have on the client.  The server compares this with the version of the calendar data that exists on the server.  If there are no changes/additions/deletions to the calendar data, Cozi returns a 304 error.  This is to reduce the load on our services.  Unfortunately, Chumby is trying to help us here.  I think they get the 304 but that the query string does not exist in their cache, so they strip the headers and try to load the appointments since Chumby feels it was not in the cache.  And Chumby is like a pit bull dog locked on this.  It will not give up and return the 304 back the client.  On subsequent attempts, we return 304s as well and don't pass a Content-Length field in the header because it is a 304.  Chumby really wants a Content-Length.  Looking at the logs I get a steady stream of errors.  Below is a snippet from the log.  I've removed some auth cookie data, but you should get the general idea.  On the first call to the services, the 'version' parameter is 0.  On subsequent ones it is > 0.

Sadly, I think Chumby is technically correct that it is not the same query string.  However, Chumby should not be handling the caching in this manner. Besides the fact that this eventually crashes the Chumby as it consinuously retries to get the data, the XML class never issues an onLoad, onHTTPStatus, or onData.  I believe the correct action by Chumby should be to get the 304 and pass it back to the application. We handle the caching in the app when we get the 304.  Versions of this widget run across a wide variety of OSs and it runs in the desktop version of the Flash control.

Any assistance would be greatly appreciated. 

Log file:

2009-05-15 08:45:12 NetStreamRequest::Open(5): Opening protocol 'http://' host 'cozicentral.cozi.com' port 80 location '/rest/api/calendar/interval/default.ashx?output=appointments,household,notes,abbreviations,location&startDate=2009-05-14T15:45:12Z&endDate=2009-05-22T15:45:12Z&tzOffset=420&account=d705e7f7-c1af-4e60-8e5c-a6c82d08dfd4&auth=<<<<removed>>>>&version=3142&apiKey=vistagadget'

2009-05-15 08:45:12 NetStreamRequest::Open(5) opened http object id 13

2009-05-15 08:45:12 HTTPCacheHeaderParse::Parse1123Date(-1) has invalid asctime() format

2009-05-15 08:45:12 HTTPCurlObject::Pump() ERROR! BROKEN SERVER sent header with no Content-Length. RFC2616 violation! (8 headers)

2009-05-15 08:45:12 HTTPCurlObject::Cancel(id=13) removing handle 0027d3d8 from multihandle

2009-05-15 08:45:12 HTTPCurlObject::Cancel() id=13 cancel forces expiration of cache entry 12!

2009-05-15 08:45:13 HTTPCurlObject::Pump() ERROR! BROKEN SERVER sent header with no Content-Length. RFC2616 violation! (16 headers)

2009-05-15 08:45:13 HTTPCurlObject::Cancel(id=13) removing handle 0027d3d8 from multihandle

2009-05-15 08:45:13 HTTPCurlObject::Pump() ERROR! BROKEN SERVER sent header with no Content-Length. RFC2616 violation! (24 headers)

2009-05-15 08:45:13 HTTPCurlObject::Cancel(id=13) removing handle 0027d3d8 from multihandle

Re: 304 Error handling

There was a fix put in for this in the 1.7 firmware release. The log snippet quoted above is from the 1.6 firmware. The error message returned by the 1.7 firmware also contains "id=xxxx" and is spew-controlled.

However, there is a (previously undiscovered and separate) bug in the way we handle 304 (Not Modified). See http://www.w3.org/Protocols/rfc2616/rfc … #sec10.3.5

The actual bug was that we would do this in relation to an error 204 (No content) which we only recently started seeing. We would mistakenly interpret this as if it was a 3xx OTHER THAN 304 (the various redirection cases) which was not compliant with RFC 2616 by having either Transfer-Encoding or Content-Length specified. We would not do this with a normal 3xx return code.

We don't cache 3xx responses unless they explicitly set TTL values in the header (which so far I haven't seen anyone do). The flash API is a bit vague when it comes to 3xx responses which are typically non-terminal.

It would also be good to see what the date format returned in your headers is - we're not able to parse it. Usually we'd do that with Expires: per http://www.w3.org/Protocols/rfc2616/rfc … l#sec14.21 which wants the date to be in RFC 1123 date format. If we're not handling that correctly it might be another bug. But you should be able to force the response to be cached via max-age=86400 or something like that.

We definitely want to reproduce this and make sure we handle all these cases properly. We would need the widget and I assume would need to set up a calendar on www.cozi.com. Any other details?

Thanks!

Re: 304 Error handling

I've put in a fix for this and I am trying to test it - I've subscribed to an account on cozi.com and I am using the widget that's available, but would like some suggestions on the conditions needed to get a 304 return. Any of the following details would be helpful:

* Is there a way to get the 304 return? I seem to always get my current calendar events
* Do I have the right widget? Is there a development widget that passes additional parameters or perhaps connects to a dev server?

Thanks!

Re: 304 Error handling

I'll upload a newer version that causes the 304.  Temporarily I have disabled the 304 and we just pull down all the data each time which is not mass production ready. It will be later tonight as I have to review some patent materials all day today.

Thanks for the quick response.  I wish every company had the same capability and motivation.

Very Best, Bill.

Re: 304 Error handling

You can also just email me the swf - it's my first name only -at- chumby.com
If you can get it over to me today I can look at it, otherwise I'll be out next week...

Thanks!

-Henry Groover

Re: 304 Error handling

Bill - you're welcome to keep the "304" widget "private" - just email us the name of the widget and we'll be able to use it.

Re: 304 Error handling

I've updated the private widget and confirmed it is generating the 304.  Please feel free to grab it for your tests.

Thanks for your supremely cool responsiveness.