[Seaside] Swazoo bugs that can affect Seaside

[Dale Henrichs]

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

Dale