Brief discussion at, where they decided to leave things as they already were. Similarly, it is in urllib3 “because that’s what cURL had by default”.
So that explains why Firefox has */* tacked on. See and Īccording to all the HTTP 1.1 RFCs, having */* at the end means you accept any other content type if none of the higher priority ones are available (otherwise you risk a 406 Not Acceptable error).
* I'm also seeing "Accept: */*" in book examples as well. * The poolmanager in urllib3 uses "Accept: */*" by default and has a comment that that and the "Host" header are both needed by proxies. * Kenneth Reitz's requests module uses "Accept: */*" by default. * Firefox includes "*/*" at the end of its list of acceptable types. * Curl (a minimalist) includes "Accept: */*", Host, and User-Agent. * The header made a difference to the Facebook Graph API. What do you think, Raymond or Senthil?īefore dismissing this, we should get a better understanding of why "Accept: */*" is so widely used in practice. I propose rejecting this one, in favour of the caller adding their own “Accept: */*” (or more preferably, “Accept: application/json”) header. I have come across the same deal with application/atom+xml vs text/xml vs application/xml. Otherwise, it would probably be more robust to make your program accept both types. If you really desire only application/json, you should probably include “Accept: application/json” in the request. I don’t understand why adding it should make a real difference. The RFC says “A request without any Accept header field implies that the user agent will accept any media type in response”, which sounds the same as “Accept: */*”. (and besides, the content-type header is unimportant when you know what to expect, which is normally the case when calling an API) Forcing an accept header may totally change the output of other servers and break existing uses. Is that a bug in urllib, or in Facebook's HTTP implementation?įrankly, we shouldn't jump to conclusions just because one specific use case is made better by this. > charset=UTF-8 (which is more desirable). > sending of Accept */* the content-type is set to application/json > The content-type returned is text/javascript charset=UTF-8 and with The content-type returned is text/javascript charset=UTF-8 and with sending of Accept */* the content-type is set to application/json charset=UTF-8 (which is more desirable). Well, the result with loading using json will be same. Will need similar addition in urllib2 and inclusion of tests.Ĭan you explain how the result is incorrect? # Example that gets an incorrect result due to the missing header The use of urllib for REST APIs is impaired in the absence of a "Accept: */*" header such as that added automatically by the requests package or by the CURL command-line tool. Urllib doesn't put Accept: */* in the headersĪrfrever, Lukasa, kennethreitz, martin.panter, orsenthil, pitrou, python-dev, rhettingerĬreated on 23:50 by rhettinger, last changed 14:58 by admin.
0 kommentar(er)
