[squeak-dev] Altitude's ALPath

Chris Cunnington smalltalktelevision at gmail.com
Fri Dec 14 23:20:06 UTC 2012


On 2012-12-14 4:43 PM, Frank Shearar 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'.
You're first string cannot be used as a url. The %20 gets added to fill 
the space. It's there because 'as is' your string cannot be used in a 
url. Added to which, if you are presenting classes from an image, you 
have an unusual resource. Perhaps you should create a new kind of 
resource for that (i.e. ALImageClassResource  as opposed to 
ALFormResource, ALHtmlResource, ALCallbackResource, ALJSONResource)?

At any rate, I sort of think that what you want to change should be 
before things go 'into the pipe' or afterwards. In your application, as 
opposed to the framework.

Just a thought,
Chris

>
> >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?
>
> frank
>
> [1] http://tools.ietf.org/html/rfc3986
>



More information about the Squeak-dev mailing list