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