Hi David: thanks for the info. As discussed on irc, I think this is great addition (as an optional arg). +1 for approach #3. Please open a ticket (with patch, when ready) at http://trac.gispython.org/lab/wiki/OwsLib and we will make sure this gets implemented.
Thanks ..Tom > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Dominic Lowe > Sent: Tuesday, 26 April 2011 10:46 > To: [email protected] > Subject: Re: [Community] cookies and OWSlib > > Hi David, > > I'd be very happy to see that patch - I'm sure there are > other circumstances when cookies would be useful in OWSLib. > > Am I right in thinking your current patch does not support > http password/username logon? I think that's pretty important > to maintain as that was a requirement from some other users. > > Otherwise I'm pretty happy for you to suggest a patch. Tom > Kralidis may have more comments as he has been most active on > OWSLib recently. > > Regards, > Dominic > > > On 25/04/11 19:07, [email protected] wrote: > > Hi all, > > > > I work on GeoNode (http://geonode.org/). We're using > OWSLib to fetch > > data from GeoNetwork. Recently I've discovered that due to the way > > GeoNetwork handles sessions, it makes a big difference for us to > > include HTTP cookies on our service requests (without them, > GeoNetwork > > creates a new session for each service request and > eventually locks up > > after running out of RAM.) > > > > Therefore I would like to modify owslib to use a > (persistent) instance of urllib2.HTTPCookieProcessor when > opening URLs, one which I can get a reference to so that I > can log in to GeoNetwork and have owslib use the session > cookie. Ideally, there would be a way to provide my own > instance of urllib2.OpenerDirector which I can customize as needed. > > > > I am currently using a monkey patch to fix this behavior, > but it's not the way I'd like to do things (you can see the > diff in GeoNode here: > https://github.com/dwins/geonode/compare/master...csw-cookies ). > > > > For a deeper fix I see basically 3 options: > > > > 1) Use Python's urllib2.install_opener to set a default > opener instance to use, and be careful not to pass arguments > into owslib methods that would cause them to create their own > openers (for example, including a username and password in a > call to owslib.util.openURL). > > 2) Create a module-level variable (owslib.util.opener) and > modify owslib.util.openURL and owslib.util.http_post to > reference it exclusively. Then client code which needs to > modify the HTTP handling behavior can simply replace this variable. > > 3) Make each client class (ie, > owslib.csw.CatalogueServiceWeb) use its own opener instance > which may be provided by client code. > > > > The attached patch is a partial implementation of approach #3. (In > > each of these cases there is the question of how to handle the > > username/password arguments to owslib.util.openURL, I haven't > > addressed this.) > > > > Is this sort of thing something the OWSLib community would > be interested in incorporating? If so I'm happy to update > this patch to incorporate feedback etc. > > > > -- > > David Winslow > > OpenGeo - http://opengeo.org/ > > > > -- > Scanned by iCritical. > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community > _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
