Hosted Images Being Returned as Text/XML

[ekarkosApollo]

Watson Webserver version: 2.1.3 .NET Framework: 4.6.2

We are having an issue where images in a directory that we host up via server.ContentRoutes.Add("/img/" + nameOfImage) are being returned with text/xml headers when our other application accesses them.

[jchristn]

Hi @ekarkosApollo could you send me an example full URL that is being requested? Thanks!

[ekarkosApollo]

So the way it works is we copy the image from its original location to a temporary cache folder next to the executable, the path to the image stored in the temporary cache would be something like <path_to_exe>\img\foo.jpg and they get hosted up on localhost:9001/img/foo.jpg.

Another separate application then grabs the image data from that URL for uploading to another web server, but for some reason that second application is getting the MIME type back as text/xml.

[jchristn]

Ok - interesting. Within ContentRouteProcessor.cs it normalizes the file name/path and then calls GetContentType which uses the MimeTypes static class internally to retrieve the content-type based on the file extension.

In the case of foo.jpg it should be resolving to .jpg which should return image/jpeg for the content-type.

You're certain that the full URL always ends in .jpg?

[ekarkosApollo]

It ends in the extension of the image. So for example, foo.jpg would be localhost:9001/img/foo.jpg but bar.tif would be localhost:9001/img/bar.tif.

[jchristn]

Got it. Do you notice this for all image types (extensions) or just certain ones?

On Aug 2, 2019, at 12:34 PM, Eric Karkos notifications@github.com wrote:

It ends in the extension of the image. So for example, foo.jpg would be localhost:9001/img/foo.jpg but bar.tif would be localhost:9001/img/bar.tif.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ekarkosApollo]

Yes we have noticed this for all file extensions.

The second application makes a GET request to the URL I create like above. I ran a debugger to check the variable storing the incoming image blob, and this is what it came up with in the debugger:

[jchristn]

Also do you see the Content-Type header reflected as text/xml when using curl -v? If you could provide some sample full URLs that would be helpful. The only extensions that should be returning text/xml are:

        {".AddIn", "text/xml"}, 
        {".disco", "text/xml"}, 
        {".dll.config", "text/xml"}, 
        {".dtd", "text/xml"},
        {".dtsConfig", "text/xml"}, 
        {".exe.config", "text/xml"}, 
        {".mno", "text/xml"}, 
        {".SSISDeploymentManifest", "text/xml"}, 
        {".vml", "text/xml"}, 
        {".vsct", "text/xml"}, 
        {".vsixlangpack", "text/xml"},
        {".vsixmanifest", "text/xml"}, 
        {".vssettings", "text/xml"},  
        {".vstemplate", "text/xml"}, 
        {".wsdl", "text/xml"}, 
        {".xml", "text/xml"}, 
        {".xrm-ms", "text/xml"}, 
        {".xsd", "text/xml"},
        {".xsf", "text/xml"},
        {".xsl", "text/xml"},
        {".xslt", "text/xml"}, 

And anything not recognized should show up as application/octet-stream

[jchristn]

Ok you definitely found a bug.

I just tested using watson.jpg within a content route and it's not setting the content-type.

I will investigate this ASAP. Thanks for letting me know!

[jchristn]

Just pushed a fix to NuGet in v2.1.4: https://www.nuget.org/packages/Watson/2.1.4

Commit is here: https://github.com/jchristn/WatsonWebserver/commit/38fbe8eccc5d7f17ea26abad9de25bd22315d6a4

Should only take ~10 minutes for NuGet to update, could you please let me know if this fixes the issue for you?

Thanks again for filing it!

[ekarkosApollo]

Looks like this fixed the issue. Thanks again for the quick responses.