[Seaside-dev] WAUrl decoding $+ when it should not (ZnUrl too)

[Johan Brichau]

Hey Sven,

Very much appreciated.

Btw, in the blogpost I reference, I do read that $+ is only permitted in the path segment. In the query segment, the $+ should be encoded (see quote below).
In the Seaside tests (and my code fragments), it happens inside the query segment. 

Quote from [2]:
For HTTP URLs, a space in a path fragment part has to be encoded to "%20" (not, absolutely not "+"), while the "+" character in the path fragment part can be left unencoded.
Now in the query part, spaces may be encoded to either "+" (for backwards compatibility: do not try to search for it in the URI standard) or "%20" while the "+" character (as a result of this ambiguity) has to be escaped to "%2B".

I had to read the blogpost again after writing the previous email to notice that. Whoever came to the idea of different reserved characters per segment really never actually implemented it :-/

Johan

On 14 Feb 2014, at 21:46, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Hi Johan,
> 
> On 14 Feb 2014, at 21:23, Johan Brichau <johan at inceptive.be> wrote:
> 
>> Both assertions above should actually be false, imho.
>> 
>> So, am I correct that we should fix WAUrl ?
>> 
>> Feedback appreciated!
> 
> Just wait a bit, I am working on it, but I was not yet ready.
> 
> I also think that the following is wrong (and silly):
> 
> ZnZincServerAdaptor>>#requestUrlFor: aZincRequest
> 	^ (WAUrl absolute: aZincRequest uri greaseString)
> 		decodedWith: self codec.
> 
> I hope to get back to you over the WE.
> 
> Sven
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev