On 14 December 2012 21:43, Frank Shearar <frank.shearar at gmail.com> wrote:
> Should ALPath decode a request's path?
>
> In particular, I'm mucking around again with reflecting images with
> Altitude, and send a GET to
> http://127.0.0.1:9090/organization/classes-in/Graphics-Display%20Objects
>
> I'd expected the resulting ALPath such that path third =
> 'Graphics-Display Objects', but it's actually path third =
> 'Graphics-Display%20Objects'.
>
> From my reading of RFC 3986 [1], especially sections 2.5 and 7.3, it
> seems like (a) it's up to the scheme definition as to how to encode
> things (beyond encoding reserved characters) and that (b) usually
> that's string -> utf-8 -> %-encoding.
>
> What do you think? Should ALPath (or ALHttpParser during construction
> of same) be responsible for shielding the application from the
> vagaries of HTTP's encoding rules?

Something like this, perhaps:

ALHttpParser >> parsePath [

	| out path |
	path := ALPath root.
	ch := in get.
	ch = Slash ifFalse: [self error].

	out := String new writing.
	[(ch := in get) = Space] whileFalse:
		[ch = Slash
			ifFalse: [out put: (Character value: ch)]
			ifTrue:
				[path := path / out conclusion reading percentDecoding get.
				out := String new writing]].
	path := path / out conclusion reading percentDecoding get.
	self assertSpace.
	^ path
]

I'm not exactly in love with the big fat duplication of "out
conclusion reading percentDecoding get", but it does work, at least,
in the sense of passing all Altitude's tests and getting my request
decoded correctly.

> frank
>
> [1] http://tools.ietf.org/html/rfc3986