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

Executing actions failing due to SOAPAction header #120

Open
agudek opened this issue May 14, 2019 · 0 comments
Open

Executing actions failing due to SOAPAction header #120

agudek opened this issue May 14, 2019 · 0 comments

Comments

@agudek
Copy link

agudek commented May 14, 2019

Executing actions seem to fail for certain remote devices due to the SOAPAction header being sent as Soapaction.

The problem was encountered while trying to open ports on an Internet Gateway Device. The remote device, a router in my case, responds with the router login page instead of a correct SOAP response. I pinpointed the problem by capturing the traffic with Wireshark and repeating it with a simple client socket in python. Changing the soapaction http header field name from Soapaction to SOAPAction fixed the issue and the router returned an expected response.

While according to the HTTP/1.1 standard this should not be an issue, as HTTP header field names are case-insensitive , the SOAP standard does not mention this case-insensitivity requirement. This means that manufacturers who implement SOAP according to the SOAP documentation may mistakenly require a case-sensitive header field name. Changing jUPnP to accommodate for this will increase the number of devices that will be supported, while not affecting the already supported devices.

My quick and dirty fix was to change the header field name value in the Type enum in org.jupnp.model.message.headerUpnpHeader from SOAPACTION("SOAPACTION", SoapActionHeader.class) to SOAPACTION("SOAPAction", SoapActionHeader.class) and skipping the header field name normalisation in org.jupnp.http.Headers by removing the contents of the normalize(String key) function. This fix is definitely not ideal, as I am not sure if it will break anything else in the library, but it seems to work correctly for me for now.

Is this an issue you would consider pursuing? And if so, what would be the ideal way to fix this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants