I have a patch coming soon (when I get authorization from my employer) that will allow the use of the host name (domain, subdomain etc.) in routes. Here''s the syntax I''m working with right now: map.connect ''//:host/:controller/:action/:id'' map.connect ''//:host/:action/:id'', :host => /two\..+/, :controller => ''two'' map.connect ''//:host/:id'', :host => /one\..+/, :controller => ''one'', :action => ''list'' The last route, for example, would route to OneController#list when the URL "http://one.localhost:3000/123" or "http://one.mydomain.com/ 123" is given. I needed some way to distinguish between routes that care about the host and routes that don''t. Thus, I''ve prepended a "//" in front to denote "I care about the host and my first symbol should be match against the host". In the example URLs above, the :host Regexp will be compared with "one.localhost" and "one.mydomain.com". I think it would be natural for most developers to prepend a ''//'' since it closely follows the URI format of protocol://domain/path? query_string. Thoughts? Duane Johnson (canadaduane)
* Duane Johnson (duane.johnson@gmail.com) [051207 14:00]:> I have a patch coming soon (when I get authorization from my > employer) that will allow the use of the host name (domain, subdomain > etc.) in routes. Here''s the syntax I''m working with right now: > > map.connect ''//:host/:controller/:action/:id'' > map.connect ''//:host/:action/:id'', :host => /two\..+/, :controller > => ''two'' > map.connect ''//:host/:id'', :host => /one\..+/, :controller => > ''one'', :action => ''list'' > > The last route, for example, would route to OneController#list when > the URL "http://one.localhost:3000/123" or "http://one.mydomain.com/ > 123" is given. > > I needed some way to distinguish between routes that care about the > host and routes that don''t. Thus, I''ve prepended a "//" in front to > denote "I care about the host and my first symbol should be match > against the host". In the example URLs above, the :host Regexp will > be compared with "one.localhost" and "one.mydomain.com". > > I think it would be natural for most developers to prepend a ''//'' > since it closely follows the URI format of protocol://domain/path? > query_string. > > Thoughts?I like the idea on some level, though I wonder: How well does it play (API-wise) with the logical extensions of asking for port, protocol, username & password (HTTP Basic)? Port is problematic due to the normal /:\d+/ pattern used. The web server often handles functional redirection based upon host. The request object will have the various URL components and a filter could be used to alter functionality based upon those URL components. All I''m saying there is that there are usually other ways to make behavior conditional. I do like the idea of being able to put that sort of control straight into the routes, but my only objection at the moment is syntactical -- not in the current suggestion but the next obvious improvement to the current suggestion. Rick -- http://www.rickbradley.com MUPRN: 785 | much ascribes to random email haiku | the unix philosophy | one tool for one job.
> I like the idea on some level, though I wonder: > > How well does it play (API-wise) with the logical extensions of asking > for port, protocol, username & password (HTTP Basic)? Port is > problematic due to the normal /:\d+/ pattern used. > > The web server often handles functional redirection based upon host. > The request object will have the various URL components and a filter > could be used to alter functionality based upon those URL components. > > All I''m saying there is that there are usually other ways to make > behavior conditional. I do like the idea of being able to put that > sort > of control straight into the routes, but my only objection at the > moment > is syntactical -- not in the current suggestion but the next obvious > improvement to the current suggestion. >Some good points, Rick. I can imagine it will extend to use the protocol quite easily, since we can search for ''//'' in the route string and check to see if there''s anything in front of it: map.connect ''proto://:host/:controller/:action/:id'' The username, password, and port, however, are a bit of a stumbling block. We *could* just throw them in to the :host (or whatever''s between // and /). With regard to username and password, I don''t think it''s wise to encourage people to route differently based on those variables. A controller should handle authentication, not the routes. As for the remaining variable, the port, it seems reasonable to include it in the :host. Or else we can add another delimiter such as a pipe: map.connect ''proto://:host|:port/:controller/:action/:id'' I''d rather this last option than combining the port in with :host. Combining them might cause difficulty when moving between webrick and apache/lighttpd. Duane Johnson (canadaduane)
* Duane Johnson (duane.johnson@gmail.com) [051207 14:30]:> As for the remaining variable, the port, it seems reasonable to > include it in the :host. Or else we can add another delimiter such > as a pipe: > > map.connect ''proto://:host|:port/:controller/:action/:id''Good points. Again, not having looked at the relevant code yet, would it be straightforward to do a simple thing and have: map.connect ''proto://:host\::port/:controller/:action/:id'' ? Rick -- http://www.rickbradley.com MUPRN: 685 | yard. Probably just random email haiku | accross the street or the next | street over would work.
On Dec 7, 2005, at 12:45 PM, Rick Bradley wrote:> * Duane Johnson (duane.johnson@gmail.com) [051207 14:30]: >> As for the remaining variable, the port, it seems reasonable to >> include it in the :host. Or else we can add another delimiter such >> as a pipe: >> >> map.connect ''proto://:host|:port/:controller/:action/:id'' > > Good points. > > Again, not having looked at the relevant code yet, would it be > straightforward to do a simple thing and have: > > map.connect ''proto://:host\::port/:controller/:action/:id'' >Yes, that would be easy enough as well. Duane Johnson (canadaduane)