Strategies for dealing with broken clients? (invalid documents) about spyne HOT 3 CLOSED

Dealing with broken clients is just normal business for a soap server.

I always thought that stuff that needs to happen before create_in_document() needs to happen in the transport layer, because at that stage of request processing, you're effectively dealing with just a byte stream, and juggling bytes around is the job of the transports. So anything you do is going to be transport-specific.

You could add a one-liner to fire an event before create_in_document but you'd have to be doing transport-specific work in it anyway. So I'm not sure that's the best thing to do. Would you agree?

from spyne.

You can have a look at examples/events.py to see how the 'wsgi_call' hook could be used to modify docs before xml parsing takes place.

from spyne.

I may be approaching my limitations and I don't want to turn this into a help forum, but I do see value in sharing what I learned.

I'm having trouble working out how I'd manipulate the context object. wsgi_call gets you an object that looks like

WsgiMethodContext(
	call_start=1629217054.327723, 
	call_end=None, 
	is_closed=False, 
	app=<spyne.application.Application object at 0x10ae31d30>, 
	udc=None, 
	transport=<spyne.server.wsgi.WsgiTransportContext object at 0x10aed62b0>, 
	outprot_ctx=<spyne.context.ProtocolContext object at 0x10aec5f40>, 
	inprot_ctx=<spyne.context.ProtocolContext object at 0x10aec5fa0>, 
	protocol=<spyne.context.ProtocolContext object at 0x10aec5fa0>, 
	event=<spyne.context.EventContext object at 0x10aed6250>, 
	aux=None, 
	method_request_string=None, 
	files=[], 
	active=False, 
	_MethodContext__descriptor=None, 
	in_string=None, 
	in_document=None, 
	in_header_doc=None, 
	in_body_doc=None, 
	in_error=None, 
	in_header=None, 
	in_object=None, 
	out_object=None, 
	out_header=None, 
	out_error=None, 
	out_body_doc=None, 
	out_header_doc=None, 
	out_document=None, 
	out_string=None, 
	out_stream=None, 
	function=None, 
	locale=None, 
	_in_protocol=<spyne.protocol.soap.soap11.Soap11 object at 0x10a5bafd0>, 
	_out_protocol=<spyne.protocol.soap.soap11.Soap11 object at 0x10ae311f0>, 
	pusher_stack=[], 
	frozen=True, 
))

If I dig into the transport object, there is a req object, which has the byte stream of the payload in wsgi.input, but that's a BufferedReader. I've had trouble "materializing" the buffered reader without causing hangs, but this is where I'd point back to my python limitations. Code like this hangs

def _on_wsgi_call(ctx):
    print("Start _on_wsgi_call")

    istream = ctx.transport.req.get('wsgi.input')

    length = str(ctx.transport.req.get('CONTENT_LENGTH', 0))
    if len(length) == 0:
        logging.warning("Empty Content")
        length = 0
    else:
        length = int(length)
        logging.warning("Content Length %s", length)

    print(istream.read(length))
    print("End _on_wsgi_call")

The server doesn't hang, but the client connection stays open and nothing is returned to the client. You may recognize some of that from __wsgi_input_to_iterable in ./spyne/server/wsgi.py. Maybe I have to jam istream.read(length) into the ctx.in_string and call another method to get it to continue.

from spyne.