[Seaside] [BUG?] The Third Ghost Request and error swallowing

[Michal]

Hi all - 

There are some weird interactions between seaside and the squeak http framework - as noted in the comment of #beginConversation. If you download the vanilla seaside 2.5 image from seaside.st and run the seaside/counter application, it turns out that each click on '++' or '--' generates 3 requests, with a problem with the third.

To see that there are 3 requests, the easiest is to put a halt at the start of #beginConversation, just before the request is created (do this once the session is already started, otherwise you'll get an initial avalanche of debuggers). A debugging session will reveal that the third request systematically answers false to 'self stream socket dataAvailable' -- there is nothing in that request, no headers, no url, no status, no nothing.

(One way to see it is to insert a line like this into #beginConversation and take it from there:

	[
		self stream socket dataAvailable ifFalse: [self halt] "<-- new debug line".
		[request := self readRequest] on: Error do: [ :ex | continue := false].

Now clicking on a link will generate some false positives where request initially answer false and then true, but the third consistently remains on false.)

Note that the third request does NOT occur on a mac if you call it as localhost (ie: http://localhost:9090/seaside/counter), but it DOES occur if you use 127.0.0.1 (ie: http://127.0.0.1:9090/seaside/counter) instead. Apart from this quirk, the ghost was consistently seen on both mac and debian servers, both from safari and firefox/mac browsers, both on local and remote servers.

This third "ghost" request triggers errors, obviously. The first error occurs in #initStatusString:, which receives an empty string and answers: ^self error: 'invalid http status line'. (Fixing that creates a cascade of errors down the line). Under normal circumstances, this error gets silently swallowed in #beginConversation, and the whole issue is thus hidden. To see the error for yourself, just stop the silent swallowing. For instance add a #pass:

		[request := self readRequest] on: Error do: [ :ex | continue := false. ex pass].

If you do that, you will need to wait a long time for the error to pop up, as the socket is trying to read for a fair amount of time before giving up. 

Although the net effect of all this is invisible to the normal seaside user, it does bite every sometime and seems generally unhealthy. It bit me today while coding some framework-internal stuff in seaside (which I will announce shortly). So: 

1. why does a seaside http interchange involve this third "ghost" request? At first sight, that looks like a bug. (I'm actually not sure it is Seaside-specific, as I didn't try with a plain comanche server yet, but if it is, it might also start to explain the comment in #beginConversation that some errors 'only happen when Seaside is also loaded'...)

2. can we stop silently swallowing errors in #beginConversation? That will make it much easier to see the issues and give some incentive to fix them instead.

Michal