Allow missing Content-Type for device and service XML

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Allow missing Content-Type for device and service XML

Michael Pujos
Hi,

I have a device that won't set a Content-Type header in device and service responses. It fails instatiating because of this.

I made checking for Content-Length less strict (won't make device creation fail) but still issue a warning

in RetrieveRemoteDescription::describe():
 ContentTypeHeader header = deviceDescMsg.getHeaders().getFirstHeader(UpnpHeader.Type.CONTENT_TYPE, ContentTypeHeader.class);
        if (header == null) {
        	log.warning("Received device descriptor without Content-Type: " + rd.getIdentity().getDescriptorURL());
        } else if (!header.isUDACompliant()) {
        	log.warning("Received device descriptor was received with an invalid Content-Type: " + rd.getIdentity().getDescriptorURL());
        }

in RetrieveRemoteDescription::readServiceDescriptor():
 ContentTypeHeader header =  serviceDescMsg.getHeaders().getFirstHeader(UpnpHeader.Type.CONTENT_TYPE, ContentTypeHeader.class);
        if (header == null) {
        	log.warning("Received service descriptor without Content-Type: " + serviceDescMsg);
        } else if(!header.isUDACompliant()) {
            log.warning("Received service descriptor with an invalid Content-Type: " + serviceDescMsg);
        }

Reply | Threaded
Open this post in threaded view
|

Re: Allow missing Content-Type for device and service XML

Christian Bauer
Administrator
Hrm, a missing content-type header is not only against the UPnP spec, it's also invalid HTTP.

I can see that it would work in most cases because the code which reads the body of an HTTP message is very defensive. If no text content-type is received, we are reading the raw bytes from the HTTP body into the UpnpMessage.body. Then we assume a new String(byte[], "UTF-8") conversion works, check the UpnpMessage.getBodyString() method.

Your device probably also doesn't send a content-type in action requests and GENA notifications. The checks for that are first in ReceivingAction and ReceivingEvent.

I need to think about this some more, maybe it's time to start on device profiles so we can make exceptions to the rules for broken devices without changing correct code all over the place.
Reply | Threaded
Open this post in threaded view
|

Re: Allow missing Content-Type for device and service XML

Michael Pujos
On 15/07/2010 08:17, Christian Bauer [via Cling users and developers]
wrote:
> Hrm, a missing content-type header is not only against the UPnP spec,
> it's also invalid HTTP.
>

from RFC2616

Any HTTP/1.1 message containing an entity-body SHOULD include a
    Content-Type header field defining the media type of that body. If
    and only if the media type is not given by a Content-Type field, the
    recipient MAY attempt to guess the media type via inspection of its
    content and/or the name extension(s) of the URI used to identify the
    resource. If the media type remains unknown, the recipient SHOULD
    treat it as type "application/octet-stream".





> I can see that it would work in most cases because the code which
> reads the body of an HTTP message is very defensive. If no text
> content-type is received, we are reading the raw bytes from the HTTP
> body into the UpnpMessage.body. Then we assume a new String(byte[],
> "UTF-8") conversion works, check the UpnpMessage.getBodyString() method.
>
> Your device probably also doesn't send a content-type in action
> requests and GENA notifications. The checks for that are first in
> ReceivingAction and ReceivingEvent.
Yes probably, will have to check when I'll be testing actions

>
> I need to think about this some more, maybe it's time to start on
> device profiles so we can make exceptions to the rules for broken
> devices without changing correct code all over the place.

 From experience, the UPnP/DLNA world if full of devices having small
and not so small quirks.
Several reasons for this: from the spec that is overly complex and
sometimes leave room for interpretation, to UPnP being an afterthought
in some products, to teams working on tigh deadlines...There are bugs
It is impossible for example to write an UPnP AV Control Point and be
sure it will work with a device until you test it with that device.
I wouldn't use device profiles for the basic functionality, I'd just
relax the parser and checks where it makes sense and on a case by case
basis, as they are discovered


Reply | Threaded
Open this post in threaded view
|

Re: Allow missing Content-Type for device and service XML

Christian Bauer
Administrator
I've committed to trunk (beta4) some changes that allow messages without or with broken content-type headers. The strategy is to assume that all entity bodies are textual and fail at the last possible moment when they are not (e.g. in the XML parsing step).

One exception though, UDA 1.0 says about action invocation messages:

'If the CONTENT-TYPE header specifies an unsupported value (other then “text/xml”) the device must return an HTTP status code “415 Unsupported Media Type”.'

So a broken content type is not OK in this situation but no content type is. I'm assuming that the UPnP certification tests are checking for this behavior.