When I try to make a request to get the comments of a specific file which contains a large number of comments (around 70000), I get a 500 Internal Server Error.
Here is the request that I am sending and the response that is coming back (I have replaced the values of the fileId and token in the request):
GET /2.0/files/[my_file_id]/comments?fields=id,message,tagged_message,created_at,item,created_by HTTP/1.1
Host: api.box.com
Authorization: Bearer [my_token]
Accept: application/json
Accept-Encoding: gzip, deflate
User-Agent: CData Data Provider Engine - www.cdata.com - Accepts: gzip
Connection: close
Response:
HTTP/1.1 500 Internal Server Error
Server: ATS
Date: Mon, 06 Feb 2017 15:19:30 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 20
Age: 82
Connection: close
Is there any reason why I am getting this kind of error?
This sounds like it might be a bug with the API. Try posting on the Box Developer forums or submitting a bug.
Related
I expect the app should respond with code 304 instead of 200.
But even IF-NONE-MATCH equals ETAG it doesn't happen.
I use 'Cache-Control: no-cache' to not store a response in cache to be validated each time. Otherwise Chrome uses it's disc cache, which is unacceptable.
Request:
GET /api/v4/record/11728 HTTP/1.1
Host: host.domain.com
Connection: keep-alive
Authorization: Basic YWRtaW467Uc2Zs0eTIwMTM=
Origin: https://host.domain.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Accept: application/json, text/plain, */*
DNT: 1
Referer: https://host-ui.domain.com/some_page
Accept-Encoding: gzip, deflate, sdch, br
If-None-Match: W/"39dcd8467e47701a69c617333f7b6dac"
If-Modified-Since: Thu, 13 Apr 2017 16:09:25 GMT
Name
Response:
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,PATCH,HEAD,OPTIONS
Access-Control-Allow-Origin: https://host-ui.domain.com
Cache-Control: no-cache
Content-Encoding: gzip
Content-Type: application/json; charset=utf-8
Date: Thu, 13 Apr 2017 16:20:31 GMT
ETag: W/"39dcd8467e47701a69c617333f7b6dac"
Last-Modified: Thu, 13 Apr 2017 16:09:25 GMT
Server: nginx/1.8.1 + Phusion Passenger 4.0.60
Status: 200 OK
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: Phusion Passenger 4.0.60
X-Request-Id: ab87433e-62bd-437f-ad7c-0e1d3f95257b
X-Runtime: 0.209121
X-XSS-Protection: 1; mode=block
transfer-encoding: chunked
Connection: keep-alive
In the application common action looks like:
def action
record = Model.find(params['id'])
if stale?(record)
hard_work_result = to_do_somethig
render json: {
success: 0,
result: hard_work_result
}
end
end
There seems to be a history behind this but short story: gzip is messing with Weak ETags
Weak ETag: ETag: W/"8763458...
Strong ETag: ETag: "8763458...
You can test that this is the problem if you use cURL and disable gzip from Accept-Encoding (or use modheaders in chrome: Disable gzip compression in chrome )
References:
Getting no 304 response in Chrome/Safari but via curl
https://masa331.github.io/2016/01/06/roda-etag-caching-gotcha.html
Weak ETAGs in Rails?
Solution?
When running from nginx itself, the problem did not occur. The first link above suggests that if you are having the problem from within nginx then adding an etag on; after the gzip on; fixes the problem. Specifically though weak etags were not returned. Running from within nginx would seem to be the only option if you want gzip enabled.
my versions
Server: nginx/1.10.2 + Phusion Passenger 5.1.2`)
ii ruby-rails 2:4.2.6-1
ii ruby2.3 2.3.1-2~16.04
Ive managed to work around the problem when running in passenger standalone by editing the nginx.conf.erb and disabling gzip. To do this, you first need to get the template of the conf file:
passenger start --debug-nginx-config
this will put a file called nginx.conf.erb in your current directory. Then you can edit this file to say:
gzip off;
and then start passenger again with this file
passenger start --nginx-config-template nginx.conf.erb
see here for details of downloading and using the nginx.conf.erb
In either case you should be able to see that weak etags are not returned
My server is set to handle CORS headers. That is by default server expects 'Origin' header from the client requests.
But when i try with google chrome client without setting 'Origin' header, I get the response.
How this works?
My request header;
GET /delete/1.0 HTTP/1.1
Authorization: Bearer 98b42f3eee1db4bc1dc8fca8e557f13
Content-Type: application/x-www-form-urlencoded
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 127.0.0.1:5555
My response header;
HTTP/1.1 200 OK
Access-Control-Allow-Headers: authorization,Access-Control-Allow-Origin,Content-Type
Host: 127.0.0.1:5555
Access-Control-Allow-Origin: *
Content-Type: application/json
Date: Fri, 03 Oct 2014 06:45:13 GMT
Server: WSO2-PassThrough-HTTP
Transfer-Encoding: chunked
This gets added automatically by Chrome. If you check the headers on your Server side you will see it comes added with the Origin.
How Chrome add it in the backend, is something Google Developers can tell.
WTF!
Building an Adobe AIR twitter search appliance using Application only auth.
https://dev.twitter.com/docs/auth/application-only-auth
I can correctly obtain my Bearer token, but ALL requests result in
HTTP/1.1 401 Unauthorized
content-encoding: gzip
content-length: 86
content-type: application/json; charset=utf-8
date: Wed, 19 Feb 2014 16:08:13 UTC
server: tfe
strict-transport-security: max-age=631138519
{"errors":[{"message":"Invalid or expired token","code":89}]}
So, what is it, INVALID or EXPIRED?
I notice that in my Response Headers for my Bearer token there is an 'expires' header with a value of Tue, 31 Mar 1981 05:00:00 GMT
Does this apply to the bearer token itself?
These ambiguous error messages are giving me (and I'm sure lots of other developers) TONS OF GRIEF!
How do we debug requests with bearer tokens when we receive this message???
Please help...anyone!!!!!!! In Oauth hell!
Are you stuck at step 3 of the process from https://dev.twitter.com/docs/auth/application-only-auth?
See also the common error cases, seems your token is invalid.
For further help, we suggest using https://dev.twitter.com/discussions to post your issue, we infrequently come here on SO, but monitor questions on our developer site daily.
GET /1.1/search/tweets.json?q=sochi HTTP/1.1
Host: api.twitter.com
Accept-Language: en-us
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/533.19.4 (KHTML, like Gecko) AdobeAIR/3.9
Accept: */*
Referer: app:/TweetMasher700.swf
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Connection: keep-alive
x-flash-version: 11,9,900,117
Cookie: xxxxxxxxxxxxxxxxxxxxx
Authorization: Bearer xxxxxxxx==
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
I had the same problem and I was able to fix the the issue doing this:
consumer_key = "put here your API key"
consumer_secret = "put here your API secret"
access_token = "put here your access token" ##remember to put the "-" that separete your owener ID and your token
access_token_secret = "put here your token secret"
auth = twitter.oauth.OAuth(access_token, access_token_secret, consumer_key, consumer_secret)
Very important to separate the consumer key and secret from the token access and secreat, becuase many people mix up the authorization and the access token, making twitter plataform deny your access.
I'm seeing the below response from some calls to a webserver:
Initial call:
HTTP/1.1 200 OK
Date: Mon, 16 Jan 2012 05:46:49 GMT
X-Powered-By: Servlet/2.5 JSP/2.1
Content-Type: text/plain
Content-Length: 78
Content-Encoding: gzip
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
X-PvInfo: [S10202.C6191.A6057.RA6008.G182D.U3FAE8760].[OT/plaintext.OG/documents]
Vary: Accept-Encoding
Set-Cookie: JSESSIONID=l9pLPT5J1tpgK19Fq2qlT0F15ryByWDLgVLz16ffWPm4qQp6nzzx!-518520380; path=/; HttpOnly
DST=rd319o00000000000000000000ffffac16018bo8200; path=/
Connection: close
Subsequent calls:
HTTP/1.1 304 Not Modified
Date: Mon, 16 Jan 2012 05:48:43 GMT
Connection: close
Etag: "pv2052dae8634d971149a927231e3ceddf"
Cache-Control: no-cache
Vary: Accept-Encoding
What I'm unclear about is that both calls return a Cache-Control: no-cache directive to the browser.
However, the second call also returns a 304 Not Modified.
Where does the server expect the page to serve the data from, given that it's been instructed not to cache the earlier response?
Interestingly, I do see the response served in the browser, so the browser appears to have cached the response, despite the no-cache directive. Why?
A response with Cache-Control: no-cache does not mean that the response must not be stored at the client at all, instead it means:
If the no-cache directive does not specify a field-name, then a
cache MUST NOT use the response to satisfy a subsequent request
without successful revalidation with the origin server. This
allows an origin server to prevent caching even by caches that
have been configured to return stale responses to client requests.
So the client is allowed to store the response in the local cache but it needs to revalidate the response by the origin server. If the server says that the response stored in the client’s cache is still valid (i. e. 304 response), the client is allowed to use the stored response to satisfy the request.
I'm trying to do HEAD requests to follow 302 links, however this link: http://news.google.com/news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
is troublesome because a HEAD request returns a 200 OK and a GET request returns the expected 302 Status code.
So I'll need to do a GET request but I'd rather not have to pay for the extra bandwidth times that will come from getting the entire HTML document. Anyone know a hack to do a GET without getting the body returned?
UPDATE: took David's advice to do a Range header but they seem to still be ignoring it
GET /news/url?sa=t&fd=R&usg=AFQjCNGrJk-F7Dmshmtze2yhifxRsv8sRg&url=http://www.mtv.com/news/articles/1647243/20100907/story.jhtml HTTP/1.1
Range: bytes=0-10
x-ms-range: 0-600
Host: news.google.com
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Location: http://www.mtv.com/news/articles/1647243/20100907/story.jhtml
Content-Length: 258
Date: Wed, 08 Sep 2010 20:28:16 GMT
Expires: Wed, 08 Sep 2010 20:28:16 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Set-Cookie: PREF=ID=ef5f1bc768645c5e:TM=1283977696:LM=1283977696:S=5n26IrEDpcQTJIb1; expires=Fri, 07-Sep-2012 20:28:16 GMT; path=/; domain=.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
File a bug with the web server's owner.
Try using the Range header in your request.
If that doesn't work, can you just hang up the connection after you get the headers you want?
In the specific example you cite, you could just pull it out of the original URL's "url" parameter. But for a more generic approach, I'd stick to David M.'s suggestions