Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spyne.protocol.soap.Soap11 checks for a transport.type value that never gets set to 'wsgi' #446

Closed
ikelos opened this issue Jul 15, 2015 · 4 comments
Assignees
Labels
Milestone

Comments

@ikelos
Copy link

ikelos commented Jul 15, 2015

In [1] on line 126, spyne.protocol.soap.Soap11 checks for transport.type to be set to 'wsgi'. I can't find anywhere in the code that would set it to that though (including the WsgiApplication wrapper for spyne apps). I was testing grafting a spyne WsgiApplciation into a CherryPy app, but a direct request to the endpoint caused the transport to come through as http, which bypasses the check for POST, and the request fails a long time later on with a MemoryError.

It's not clear whether the WsgiTransportContext should set its own type to 'wsgi' or whether the GET check should apply to all http transports? I had difficulty finding any clear documentation on the use of the transport.type variable. Any help in getting this resolved would be much appreciated. If you need any further information please just ask. Thanks!

[1] https://github.com/arskom/spyne/blob/master/spyne/protocol/soap/soap11.py

@plq plq added the Defect label Jul 28, 2015
@plq plq added this to the 2.12 milestone Jul 28, 2015
@plq plq self-assigned this Jul 28, 2015
@plq
Copy link
Member

plq commented Jul 28, 2015

that's an artifact from a long lost time :) thanks a lot for reporting it.

plq added a commit to plq/spyne that referenced this issue Jul 28, 2015
@plq
Copy link
Member

plq commented Jul 28, 2015

could you please test the latest patch and let me know whether this resolves this issue?

@ikelos
Copy link
Author

ikelos commented Aug 13, 2015

Hiya, yep that seems to work fine. Thanks! Happy for you to close this...

@plq
Copy link
Member

plq commented Aug 13, 2015

thanks!

@plq plq closed this as completed Aug 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants