[Seaside] bad request

[Otto Behrens]

> This is my suggestion: Create the WARequestContext on the native
> request without parsing it.
>
> Parsing the URL effectively comes down to handleFiltered: on
> WADispatcher that will try to get the url via the consumer on the
> request. If parsing it breaks, the request is marked as a bad request.
> The dispatcher could pass to the default handler. The parsing errors
> of the other parts of the request would then go to the handler
> dispatched to. And that could in turn be dispatched to an error
> handler.

I got this to work in our application. I added adaptor and
nativeRequest to WARequest, and constructed it with these:

WAServerAdaptor >> requestFor: aNativeRequest
"Answer a request object for aNativeRequest."

^ WARequest basicNew
adaptor: self;
nativeRequest: aNativeRequest;
yourself

I then lazy initialized the variables on WARequest, using the messages
in the current version of requestFor:. For example:

WARequest >> uri
^ uri ifNil: [ uri := adaptor ifNotNil: [ (adaptor requestUrlFor:
nativeRequest) seasideUrl ] ]

This could be better, I suppose (I personally don't really like lazy
initializations). But a lot of tests construct the request with
specific URLs, methods and what not. So I would need to refactor these
to use a simple native request. I then changed WARequestContext to be
aware of a parsing error (must be better, should be on request
itself...)

The reason why this reports in our application is because the parsing
of the url is invoked again later on in the process, which throws an
exception.

The source modifications are here:
https://github.com/finworks/Seaside30/tree/handleRequestParsingError.
(A fork from https://github.com/glassdb/Seaside30)

1. Please let me know if you think this can generally work
2. Do you think I should continue and make the changes on Seaside "trunk"?
3. I suppose http://www.squeaksource.com/Seaside30LGPL is the place to do it?
4. Seaside 3.1 only?

Cheers
Otto