[Zope3-dev] Opera url parameter troubles

[Paul Everitt]

Does this url parameter issue only apply to browsers, or will it in the 
future also apply to programs that interact with Zope via web services? 
  If so, it would be pretty funny to think that most versions of Python 
in use wouldn't work Zope. :^)

I don't think it's bending over backwards to cater to the browser, it's 
bending over backwards to cater to the user of the browser, which is 
rarely a recipe for disaster. :^)  In this case, though, we might have 
to tell a class of user: "You're out of luck."  But that should be a 
last resort.

Stated differently: does developers will be hamstrung in creating 
applications for Zope that they can deploy to users of Opera?  Are there 
any conditions under the url parameter will reveal itself on, for 
instance, a portal app or an intranet?

--Paul

Tres Seaver wrote:
> Chris Withers 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?
> 
> 
> 
> I disagree;  bending over backward to cater to non-compliant
> browsers is a recipe for disaster.  Unless somebody can come
> up with a namespace discrimination scheme which sucks less,
> of course;  we wrangled about this for quite a bit:
> 
> 
> <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNamespaceControlInURLs> 
> 
> 
> Tres.