[squeak-dev] Altitude's ALPath

Frank Shearar frank.shearar at gmail.com
Sat Dec 15 13:21:47 UTC 2012


On 15 December 2012 00:14, Chris Cunnington
<smalltalktelevision at gmail.com> wrote:
> On 2012-12-14 6:47 PM, Frank Shearar wrote:
>>
>> On 14 December 2012 23:20, Chris Cunnington
>> <smalltalktelevision at gmail.com> wrote:
>>>
>>> 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)?
>>
>> I know why the %20 appears - because I (have to) URL encode things
>> that go into a URL.
>
> This problem seems like GIGO. Perhaps you are putting untreated input into a
> process and then not getting the desired result.

No, it's the opposite: my treated input arrives at the server and is
_not_ de-treated back into a decoded form.

>> My point is that I'd expected the parser to
>> un-escape percent-encoded URL parts, because that encoding is part of
>> how HTTP works, not part of how the application works. (But I suppose
>> that the current behaviour is symmetrical: you have to encode strings
>> yourself, and you have to decode strings yourself.)
>
>
> I'm pretty certain there is an API for adding HTTP streaming treatment. If
> you want to add something from a RFC, then add a Relay to do it. Look at
> ALTerminalRelay, ALStorageRelay. Add your filter there and not in
> ALHttpParser. I bet you could find one of the many Xtreams
> filters/transforms to do what you want, put it in a relay, and solve your
> problem. See Xtreams-Transforms. I sort of feel everything in Altitude is a
> stream.

Sure, but this isn't an HTTP streaming thing. It's the decoding of a
(very small) part of the request.

But hopefully a later version will fix things, so I'll report back
once I've upgraded.

frank

>> I use ALJsonResource instances, actually.
>
> I think I recall now.
>
>>   I don't surface the classes
>> directly: I'm basically (re-)implementing SystemOrganizer's and
>> ClassOrganizer's APIs locally, and serving up chunks of strings
>> remotely. For instance,
>>
>> ReflectedSystemCategories >> renderSystemCategoriesOn: json
>>         json object: [
>>                 json name: 'type' value: 'system-categories'.
>>                 json name: 'category-names' array: [
>>                         SystemOrganizer default categories do: [:cat |
>>                                 json value: cat]]]
>
> Perhaps you should subclass ALJSONResource so you can treat:
>
>                     SystemOrganizer default categories do:
>
> to produce input that doesn't leave spaces in string names. If I understand
> your problem correctly, you wouldn't have this problem if you treated your
> input.
>
> Chris
>
>
>
>> (I'm trying out the idea of faking these APIs to turn a Browser
>> (subclass) into a RemoteBrowser. Sort've a follow-on/extension of
>> Reflect-Core's experiment. First thing to note: you really want to
>> memoize the calls, because Browser makes A LOT of calls to the
>> organizers - every time it renders itself, in fact.)
>>
>> frank
>>
>>> 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