[Zope3-dev] Opera url parameter troubles

[Jim Fulton]

Casey Duncan wrote:
> 
> On Monday 18 February 2002 02:31 am, Chris Withers allegedly wrote:
> > Fred Drake wrote:
> > > On Sat, 16 Feb 2002 17:36:15 -0600 (CST)
> > >
> > >  sean.bowman@acm.org wrote:
> > > > POST /RolePermissionsManagement;view/action/ HTTP/1.1
> > >
> > > Until recently, Python's urlparse module got it wrong too.
> > > Using parameterization on path segments other than the last
> > > is probably poorly supported in general, simply because it
> > > hasn't been used a lot, so browser support for it has been
> > > poorly tested.
> > >
> > > It doesn't help that the RFCs have changed over time, which
> > > only serves to complicate implementations.
> >
> > To me, this reads as "this is bad, we shouldn't be generating URLs that
> > have parameters in anything but the last section"
> >
> > What do other people think and how do we get around it?
> 
> We discussed this at some length during the sprint before the conference. The
> problem is that if you can only supply parameters at the end of the URI, then
> a relative link will strip those parameters off, changing the view
> inadvertently.
> 
> So the solution was to move the parameters up to that they would not get
> stripped off as in:
> 
> http://foo/barView;view/spam/eggs
> 
> Since ppl are gonna want to use relative URLs, this was the best solution we
> could come up with that didn't involve cookies or session tracking.

This doesn't apply to views. The view parameter is a namespace
specifier and must go with the name it modified.

What we discussed in the sprint was the use of URI parameters to hold request
data, such as skin selection:

  http://foo.com/barView;skin=blue/spam/eggs


> It's ironic that this would not be supported by browsers, since I thought the
> whole point was to let you specify parameters anywhere in the URI, instead of
> just off the end like with CGI variable assignments. 

Parameters are can be used in any path segment except the first
segment in a relative URL. See RFC 2396, section 3.3.

> Its also ironic that
> adhering to "standards" like this causes problems, that could probably be
> solved by coming up with our own, non-standard encoding scheme.
> 
> I agree that catering to browsers is bad(tm), but so is alienating users (who
> tend to be pretty religious about browsers). Then again, if we follow the
> standard and some browser doesn't conform, and thereby doesn't work, I don't
> feel too much pity 8^).

If anyone has a better solution to the problem after reading
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNamespaceControlInURLs, 
I'm open to suggestions. :)

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org