9

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 http://api.stackoverflow.com/0.8/stats) 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/vnd.ms-excel, application/vnd.ms-powerpoint, 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
Host: api.stackoverflow.com

Chrome 6:

GET /0.8/stats HTTP/1.1
Host: api.stackoverflow.com
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.

Improve this question
3
  • 1
    I get this error from work (behind a corporate firewall) but not at home. I haven't yet found a workaround.
    – lfoust
    Commented May 20, 2010 at 17:39
  • 4
    @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
    Commented May 21, 2010 at 3:39
  • @Kevin Montrose - you can mark this one as completed; it's been working properly whole day from corpnet.
    – Franci Penov
    Commented May 22, 2010 at 3:11

1 Answer 1

Reset to default
11

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.

Improve this answer
5
  • 1
    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
    Commented May 20, 2010 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
    Commented May 20, 2010 at 18:01
  • 1
    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
    Commented May 20, 2010 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 secure.api.stackoverflow.com) also mangle https. Still, that would be a rare case.
    – Tim Post
    Commented May 20, 2010 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
    Commented May 21, 2010 at 2:01

You must log in to answer this question.

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