[Seaside] Swazoo bugs that can affect Seaside

[Philippe Marschall]

2011/8/3 Dale Henrichs <dhenrich at vmware.com>:
> In the last week or so, I've run into a couple of bugs in Swazoo that may be of interest to any Seasiders using Swazoo in their applications. I've got workarounds for GLASS if anyone is interested.
>
> The first bug is in SwazooURI where the query fields in an URL will be incorrectly parsed if an `&` or other special character is embedded in the value of the field. The following example illustrates the bug:
>
>  | url ans1 ans2 |
>  url := 'www.foo.com/index.html?foo=1&bar=', 'bar"sample method"^#($&)' encodeForHTTP
>  ans1 := SwazooURI fromString: url.
>
>  ans2 := SwazooURI new.
>  ans2 fromStream: url readStream.
>
>  ans1 printString = ans2 printString
>
> SwazooURI>>fromString: (called by SwazooURI class>>fromString:) prematurely decodes the input string exposing the `&` and causes the parser to think that there is an additional query field in the input url and results in the truncation of the value of the `bar` field. The fix is to remove the call to HTTPString class>>decodedHTTPFrom: from SwazooURI>>fromString: ... the subsequent parsing of the queryfields already call HTTPString class>>decodedHTTPFrom:
>
> This bug is present in Swazoo-2.3beta2.6
>
> ----
>
> The second bug is in WASwazooAdaptor>>requestUrlFor:. In this case WAUrl is fed the printString of the #uri (an instance of SwazooURI) as follows:
>
>  requestUrlFor: aNativeRequest
>        | url |
>        url := ((WAUrl absolute: aNativeRequest uri printString)
>                decodedWith: self codec).
>        aNativeRequest isEncrypted
>                ifTrue: [ url scheme: 'https' ].
>        ^ url
>
> The problem occurs because WAUrl class>>absolute: expects the url to be url encoded, but the printString for SwazooURI prints the decoded url. Again this causes problems when HTTP special characters are in the input url. The other adaptors feed the 'raw' encoded url string to WAUrl, but the Swazoo adaptor does not ... SwazooURI does not keep the encoded source url around, so in my workaround I changed SwazooURI printQueriesOn: to reencode the query parameters ...

Since it's already parsed I think it would be better to create the
WAUrl from the SwazooURI without serializing and parsing again. I'll
look into it.

http://code.google.com/p/seaside/issues/detail?id=674

Cheers
Philippe