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
