Smalltalk › Frameworks & Tools › Seaside › Seaside General

iCal feed to Drupal

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Bob Nemec

iCal feed to Drupal

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

Thanks again for everyone's help,

Bob Nemec
Cherniak Software
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Nemec

Michael Lucas-Smith-3

Re: iCal feed to Drupal

[hidden email] 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.

Cheers,
Michael
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Nemec

Re: iCal feed to Drupal

In reply to this post by Bob Nemec

>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)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Nemec

Re: iCal feed to Drupal

A (late) follow up: a while ago I posted about problems with an iCal feed from VW to Drupal. The request VW was processing contained training hex '0' values which caused problems with the parser. The fix was a VW code change (resolution 97157). Things are working fine now.

The code change is in VW 7.7 ... our version of the method HttpBuildHandler>>shouldStartMessageBody: was missing...

(message isResponse not and: [ message method asSymbol == #GET]) ifTrue: [^false].

The method should be:

HttpBuildHandler>>shouldStartMessageBody:

| message |

message := aMessageBody parent.

message isMimeEntity ifTrue: [^true].

(self headerOnly or: [message headerOnly]) ifTrue: [ ^false ].

" In particular, the convention has been established that the GET and

HEAD methods SHOULD NOT have the significance of taking an action

other than retrieval."

(message isResponse not and: [ message method asSymbol == #GET]) ifTrue: [^false].

^message contentLength

ifNil: [ message isChunked or: [ message isConnectionTransient ] ]

ifNotNil: [ :length | length > 0 ]

Thanks to the VW tech support (in this case, James T. Savage).

Bob Nemec

Cherniak Software

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bob Nemec