Message146401
> I’d say that urlparse should raise an exception when a ws/wss URI contains a fragment part.
Yep, better.
> I’m not sure this will be possible; from a glance at the source and a quick test, urlparse will happily break the Generic URI Syntax RFC and return a path including a # character!
That's unfortunate.
In that case I'd probably prefer the lesser evil, namely that urlparse be set up (falsely) such that ws/wss scheme would falsely allow fragments, so I get back the non-empty fragment as a separate component, and check myself.
If urlparse returns the fragment (falsely) within path, then a user could check only by searching for # in the path. Also hacky .. even worse than compare fragment for != "".
Essentially, this would be exactly "the hack" that I posted in my very first comment:
urlparse.uses_fragment.extend(wsschemes)
===
Alternative: make this bug dependent on fixing urlparse for fragment rules in generic URI RFC and don't do anything until then? |
|
Date |
User |
Action |
Args |
2011-10-25 21:00:57 | oberstet | set | recipients:
+ oberstet, orsenthil, ezio.melotti, eric.araujo, nailor |
2011-10-25 21:00:57 | oberstet | set | messageid: <1319576457.08.0.637351405698.issue13244@psf.upfronthosting.co.za> |
2011-10-25 21:00:56 | oberstet | link | issue13244 messages |
2011-10-25 21:00:56 | oberstet | create | |
|