[Seaside] iCal feed to Drupal

Michael Lucas-Smith mlucas-smith at cincom.com
Thu Sep 24 21:27:32 UTC 2009

bobn at rogers.com wrote:
> Turns out our issues with providing an iCal feed to Drupal were caused by Seaside code in VW. 
> The current one-click Pharo image works fine.  I tried it with a simple test... 
> renderContentOn: html
>  | response doc string | 
>  string := self iCalText.
>  doc := string asMIMEDocumentType: 'text/calendar;charset=utf-8'.
>  response := WAResponse new.
>  response
>   contentType:  'text/calendar; charset=UTF-8';
>   nextPutAll: doc content;
>   yourself.
>  response doNotCache.
>  self session returnResponse: response.
> ...the same code used in VW causes a one minute delay before the response, for which a retry is sent, and that adds up to a two minute delay before Drupal responds.  I'll try more recent Seaside code for VW, but the problem is related to Drupal sending a HTTP/1.0 request. 
> Eventually, you end up in SeasideHttpBuildHandler>>safelyRead:from:into: which waits on #atEnd sent to Net.BodyStream (which wraps an ExternalReadStream on a 20480 element ByteArray).  The browser HTTP/1.1 request does not trigger this code.
> It would be interesting to hack this down to the root cause, but I'd rather try the beta 3.0 VW code first.  I've burned a bit too much time on this already (it was really nice seeing Pharo work out of the box; nicely done).
I'd be interested in hearing what you find. If it's HTTP/1.0, then one 
of two modes should happen:
a) data is sent, connection is closed
b) content-length is in the header, data is sent, connection is closed

HTTP/1.0 does not have a persistent connection mechanism. That means if 
the server doesn't hangup the call or specify the content-length, it's 
not doing HTTP/1.0.

You should be able to confirm what's going on there fairly easily.


More information about the seaside mailing list