Altitude's ALPath
Locked
 
|
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? frank [1] http://tools.ietf.org/html/rfc3986 |
|
|
On 14 December 2012 21:43, Frank Shearar <[hidden email]> 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 |
|
|
In reply to this post by Frank Shearar-3
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 > |
|
|
On 14 December 2012 23:20, Chris Cunnington
<[hidden email]> 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. 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 use ALJsonResource instances, actually. 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]]] (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 >> > > |
|
|
On 2012-12-14 6:47 PM, Frank Shearar wrote:
> On 14 December 2012 23:20, Chris Cunnington > <[hidden email]> 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. into a process and then not getting the desired result. > 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. > > 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]]] 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 >>> >> |
|
|
In reply to this post by Frank Shearar-3
On Fri, Dec 14, 2012 at 4:43 PM, Frank Shearar <[hidden email]> wrote: Should ALPath decode a request's path? What version of AL-Http are you using? The above should work right as of cwp.42. Colin |
|
|
In reply to this post by Chris Cunnington
On 15 December 2012 00:14, Chris Cunnington
<[hidden email]> wrote: > On 2012-12-14 6:47 PM, Frank Shearar wrote: >> >> On 14 December 2012 23:20, Chris Cunnington >> <[hidden email]> 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 >>>> >>> > > |
|
|
In reply to this post by Colin Putney-3
On 18 December 2012 00:56, Colin Putney <[hidden email]> wrote:
> > > > On Mon, Dec 17, 2012 at 3:02 AM, Frank Shearar <[hidden email]> > wrote: > >> >> I was going to say "ConfigurationOf please", but on second thought >> perhaps an Installer script would be lighter weight. Other than >> hacking up ConfigurationOfs to support offline loading, I haven't >> properly tried decent multi-package scripts, so I don't know how much >> pain is involved in writing them. >> >> I'd prefer lots of little mostly-coherent "releases". Really, the only >> thing I want to avoid is me stubbing my toes and you explaining why >> Foo-11 needs Bar-12, not Bar-11 or something. > > > Ok, sounds good to me. > > I'll try to get a release together in the next few days. > > Colin Hi Colin, Might I be so rude as to ask how it's going? I'd love to hack up a quick "Hello, World" style website. I know there's the original Installer script you published a while back, and I know you've loads of improvements that I'm pretty sure I'd love to have. frank |
|
|
On Wed, Jan 16, 2013 at 5:52 PM, Frank Shearar <[hidden email]> wrote:
It's coming a long nicely, actually. I've delayed making a release because AL-Storage and AL-User have been evolving rapidly. I'm travelling tomorrow, so I won't be able to do a release until the weekend. Hang in there!
Colin |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |