[Seaside] Re: iCal feed to Drupal

[Bob N.]

>Michael

>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.

The problem seems to be Drupal data that VW has difficulty parsing,
which does not get triggered when the same request gets sent by a
browswer (which made debugging interesting).

>From a browser (HTTP/1.1) HttpBuildHandler>>shouldStartMessageBody:
answers false because HttpRequest>>isConnectionTransient is false (as
expected).  So we don't send #parseBody:from: which sends
#safelyRead:from:into:

The sourceStream (BodyStream) that Drupal sends has the large
ExternalReadStream, size = 20480.  From index 117 to end is all zeros
(don't know if that's relevant).

HttpParser>>parse:
header =
	Host: csws2.cherniaksoftware.com:48138
	User-agent: Drupal (+http://drupal.org/)

entity =
	GET /seaside/Bookings HTTP/1.0
	Host: csws2.cherniaksoftware.com:48138
	User-agent: Drupal (+http://drupal.org/)

...>>parseMessageBody: entity from: aStream.

The message trace is...

	BodyStream>>atEnd
	ExternalReadStream>>atEnd
	...>>endTest
	...>>nextBuffer
	IOBuffer>>nextAndSetOffset:
	...>>readBufferStartingAt:
	SocketAccessor(IOAccessor)>>readInto:startingAt:for:
	...>>primReadInto:startingAt:for:
	<primitive: 660>

	*** wait here for one minute ***

The debugger masks the problem (no wait), so this was traced with
Transcript messages.

It's simple enough to test.  If it's helpful I can trigger the Drupal
request from a public URL (ping me offline: bnemec at
cherniaksoftware.com)