src.sencha.io with images fetched with URL parameters and no file extension (but correct content type)

Question

I have an image at http://profiles.ucsf.edu/Thumbnail.ashx?id=4926871 and I try to run it through src.sencha.io, but when I do something like http://src.sencha.io/80/http://profiles.ucsf.edu/Thumbnail.ashx?id=4926871, then I get a 400 error (Bad Request) from src.sencha.io.

I have tried escaping the ? character (http://src.sencha.io/80/http://profiles.ucsf.edu/Thumbnail.ashx%3Fid=4926871) but that didn't work either.

I even tried double escaping it just to be sure (http://src.sencha.io/80/http://profiles.ucsf.edu/Thumbnail.ashx%253Fid=4926871) but no dice.

I checked to see if profiles.ucsf.edu was returning a wonky content type, but it's returning image/jpeg so that should be cool.

I tried tricking src.sencha.io by appending &.jpg to the end of the URL to see if maybe it was depending on a file extension but that didn't work.

Based on a thread in the Sencha forum, I tried http://src6.sencha.io/80/http://profiles.ucsf.edu/Thumbnail.ashx?id=4926871 but no luck there either.

If I copy the image somewhere else and run it through src.sencha.io with a URL that does not have a URL parameter, it works. I uploaded it to https://i.sstatic.net/NQsaZ.jpg and tried to access it at http://src.sencha.io/80/https://i.sstatic.net/NQsaZ.jpg.png and it was fine.

Is there something I can do to get src.sencha.io to play nicely with the profiles.ucsf.edu URLs or am I out of luck?

Answer 1

The source server is not setting the HTTP Content-length header (nor using chunking):

sh-4.1$ wget http://profiles.ucsf.edu/Thumbnail.ashx?id=4926871
--2012-09-26 14:50:53--  http://profiles.ucsf.edu/Thumbnail.ashx?id=4926871
Resolving profiles.ucsf.edu... 64.54.132.33
Connecting to profiles.ucsf.edu|64.54.132.33|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [image/jpeg]

At present src.sencha.io will fail on any HTTP response that omits the Content-length header, and does not use chunked encoding. This is a side-effect of the server checking the response size for resource constraint reasons. The 400 status is somewhat confusing in that really the operation failed due to a constraint violation, but the 400 response page talks only about input parameter correctness.

This explains why your request works when the image is copied to a different HTTP server. That server is setting the Content-length header:

sh-4.1$ wget http://imgur.com/L91W7.png
--2012-09-26 15:05:05--  http://imgur.com/L91W7.png
Resolving imgur.com... 54.243.206.51, 23.23.110.81, 23.23.110.58
Connecting to imgur.com|54.243.206.51|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://i.imgur.com/L91W7.png [following]
--2012-09-26 15:05:05--  http://i.imgur.com/L91W7.png
Resolving i.imgur.com... 72.21.81.253
Connecting to i.imgur.com|72.21.81.253|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 72842 (71K) [image/png]

The only workaround I know of at present is to arrange for your HTTP server to either send a chunked response, or set the Content-length header. The HTTP 1.1 spec allows the server's response since it closes the connection, but src.sencha.io won't accept that response at present.

Your server is IIS 6.0. I did a little research to see if omitting the Content-length header is a known bug in IIS 6.0. Results are inconclusive. There is some talk of a "compress static files" option that can cause this trouble but may be a red herring. The problem could be in a broken proxy somewhere, as discussed in this post.

By the way, beware when diagnosing this that we often see "client-side" network devices that will fix up an HTTP response with a missing Content-length header (!), either adding it or transforming the response into a chunked one. So be sure to test from a machine that has 100% clean connectivity and no proxies or other shenanigans-inducing boxes in the way.