Stack Apps is a question and answer site for apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Not sure if this is a user or an API problem, but I keep getting HTTP 406 Not Acceptable when making API calls (for example from either IE 8 or Chrome 6.

Here are the headers for the two requests.

IE 8:

GET /0.8/stats HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/, application/, application/msword, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; Zune 4.0; .NET4.0C; .NET4.0E; InfoPath.3)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive

Chrome 6:

GET /0.8/stats HTTP/1.1
Proxy-Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.9 (KHTML, like Gecko) Chrome/6.0.401.1 Safari/533.9
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Update: Awesome news! After the latest changes by @Kevin the API works as expected behind the corpnet proxy for me.

share|improve this question
I get this error from work (behind a corporate firewall) but not at home. I haven't yet found a workaround. – lfoust May 20 '10 at 17:39
@lfount you and Franci should try again. The API will still respond with gzip'd (or deflate'd) content, but it won't throw a 406 back if a proxy strips it out along the way. Let me know if that solves your problem, as I'm afraid the "on SO at work" scenario may be pretty common... – Kevin Montrose May 21 '10 at 3:39
@Kevin Montrose - you can mark this one as completed; it's been working properly whole day from corpnet. – Franci Penov May 22 '10 at 3:11
awesome, thanks for checking that out. – Kevin Montrose May 22 '10 at 3:29
up vote 11 down vote accepted

It could be a proxy between you and the API that is mangling the headers that are being sent and making the request without compression. This is one downside to mandatory compression.

It might be nice if there was an https endpoint that could be hit to test these types of issues or even to fall back to. If the point of mandatory compression is to save bandwidth then using https should be acceptable.

share|improve this answer
I agree that it is fine to have compression on by default but I don't think allowing the ability to turn it off will really be wasting that much bandwidth. – lfoust May 20 '10 at 17:56
Yes, I am making the request from my corpnet, so you could be right. I also have the ISA Firewall Client, so I wonder if it could be the culprit. – Franci Penov May 20 '10 at 18:01
I think an https endpoint would be a good compromise since it would bypass any firewall in between. If nothing else it would be nice to have at least one call exposed via https so this type of thing could be verified. – carson May 20 '10 at 18:07
I agree, mostly. There are some cases when HTTP proxies (especially in corporate offices where your browser comes loaded to trust the company CA, thus letting the proxy pretend to be also mangle https. Still, that would be a rare case. – Tim Post May 20 '10 at 18:38
On my home network this was caused by my ISP's web acceleration proxy. I found a way to bypass the proxy, but it may be more difficult in a corporate environment. – Joel May 21 '10 at 2:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .