[Seaside] Re: WAKom not responding to requests

[Nevin Pratt]

I've got an interesting data point:

I've subclassed WAKom.  My subclass is called 'ComancheInterface'.  It's 
#process: method looks like this:

***********
process: aRequest
    "This is the required Comanche method that kicks everything off. 
    Nothing else works until this method is properly run, and it will 
    automatically be run by Comanche."
    | url |
    WebHit logRequest: aRequest.
    httpRequest _ aRequest.
    url _ httpRequest url.
    (url beginsWith: '/seaside/')
        ifTrue: [^ super process: aRequest].
    ((url beginsWith: '/secure/')
            and: [httpRequest ipString ~= '127.0.0.1'])
        ifTrue: [^ self redirectToSecurePort].
    (url endsWithAnyOf: MicrosoftRedirects)
        ifTrue: [^ self redirectToMicrosoft].
    (url endsWithAnyOf: SenderRedirects)
        ifTrue: [^ self redirectToSender].
    self processMultipartFields: aRequest.
    ^ self siteManager process: httpRequest
**********

You will notice that if the URL begins with '/seaside/', the normal 
WAKom code is used.  Otherwise 'ComancheInterface' is treated as a 
normal Comanche module.

Well, if I hit any web page that does NOT begin with '/seaside/', 
everything always works.

But, if I hit a '/seaside/' page, and start running a Seaside app, every 
once in a while a page within the app DOES NOT REFRES!.  It leaves the 
browser window completely blank (I'm using NetScape 7.0 on Linux), and I 
have to explicitly click the browser refresh button to get the page to show.

It's weird.  It only happens once in awhile, but it is happening.  And, 
since I *never* see the problem for normal Comanche module page 
requests, it appears to be a Seaside issue.

Is this what you are seeing?

Nevin

P.S. In case anyone is curious, for the rest of the Comanche module, if 
I detect any known Windows-specific virii or worm probes, I forward the 
request to http://www.microsoft.com via the #redirectToMicrosoft method 
(since I consider them to be the responsible party for all such 
Windows-specific virii and worms, because of the general unsecured 
nature of their OS).  Likewise, if I detect any kiddi scripts attempting 
to probe the system, I redirect the request back to the originator, via 
#redirectToSender.  And, since I use Stunnel for secure communications, 
all secure page requests should come in via localhost IP of 127.0.0.1. 
 Any secure page request that does not come in via that IP is redirected.




Derek Brans wrote:

> These are the result of running netstat at different times.  Does 
> anyone make anything out of this?
>  
> Thank you,
> Derek
>  
> First, just after I reboot my image:. 
> netstat -an | grep 8002
> tcp        0      0 0.0.0.0:8002            0.0.0.0:*               LISTEN
>  
> then when I try to access seaside
> netstat -an | grep 8002
> tcp      500      0 127.0.0.1:8002          127.0.0.1:2015          
> ESTABLISHED
> tcp        0      0 127.0.0.1:2015          127.0.0.1:8002          
> ESTABLISHED
> tcp        0      0 0.0.0.0:8002            0.0.0.0:*               LISTEN
>  
> then again later when I try to access seaside again.
> netstat -an | grep 8002
> tcp      500      0 127.0.0.1:8002          127.0.0.1:2017          
> ESTABLISHED
> tcp        0      0 127.0.0.1:2017          127.0.0.1:8002          
> ESTABLISHED
> tcp      501      0 127.0.0.1:8002          127.0.0.1:2015          
> CLOSE_WAIT
> tcp        0      0 127.0.0.1:2015          127.0.0.1:8002          
> FIN_WAIT2
> tcp        0      0 0.0.0.0:8002            0.0.0.0:*               LISTEN
>
> Derek Brans
> Nerd on a Wire
> Web design that's anything but square
> http://www.nerdonawire.com
> phone: 604.874.6463
> mailto: brans at nerdonawire.com <mailto:brans at nerdonawire.com>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Seaside mailing list
>Seaside at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/listinfo/seaside
>  
>