I am working with rails, and returning a json response with the below method
def return_json
render json: params
end
When i am viewing the response on chrome developers tools, everything seems to be right. But when i trace the HTTP response on wireshark, on HTTP response body it seems that some extra characters exists.
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Wed, 05 Jul 2017 17:07:48 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: max-age=0, private, must-revalidate
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Runtime: 0.433854
X-Request-Id: f46a0e87-6969-4285-9b80-da0223edac01
X-Powered-By: Phusion Passenger 5.1.5
Status: 200 OK
49
{"device_attributes":[{"id":"85","value":"35"},{"id":"80","value":"65"}]}
0
(extra empty line)
I'm talking about the number 49 which is in hex and it seems to be the length of the JSON string. And after that it follows a 0 with an empty line.
Wireshark screenshot which shows the response
First of all, i would like to ask, what a valid HTTP response look like?
I think that after headers, follows an empty line and then the response body and after that nothing.
And second why rails do that and if there is a way to change that. I think that rails do that, because i get the same response from apache + phusion passenger and also puma. Also i tried this from some other code, not related to rails, and the HTTP response it was as i explained earlier and not as rails does.
I did not found out the answer i was looking for, but a workaround in order for the extra info to be removed, is to render as follows:
render plain: ActiveSupport::JSON.encode({ result: :ok })
This work around does set content-type as 'text/plain' and not 'application/json'. If you set content-type in render options as 'application/json' this extra info are being displayed again.
So i will assume that has something to do with the json renderer module, but i can't research it more at this time.
Related
I'm trying to export a Google Slides file using the Drive API. To do that, I'm using one of the export links mentioned here.
Generally, it works fine, however for some of the files I'm getting "413 Request Entity Too Large". From what I've seen so far:
When I use the export link mentioned above, I get a "307 Temporary Redirect" response. It has a "Location" header with the actual download link.
It's when using the second URL when I see the "413 Request Entity Too Large"
I believe it's actually about the URL length (even though I would have expected a 414 code?). The reasons I believe it's about the URL length are:
When using the API explorer and entering a huge fileId, I get the same response.
A similar limitation is mentioned for URL in a batch request (source):
Note: There is an 8000 character limit on the length of the URL for each inner request.
With that, my questions would be:
Is my assumption correct, i.e. that this issue is about URL length?
How to work around this issue?
UPDATE
More details about the URLs and how I execute requests.
The export link is something like: https://docs.google.com/feeds/download/presentations/Export?id=1E3AU3Tf3zB_rest_of_id_goes_here&exportFormat=pptx&xoauth_requestor_id=myemail#example.com
Then I use the following code to build and execute the download request:
Drive client = …;
HttpRequest httpRequest = client.getRequestFactory().buildGetRequest(new GenericUrl(downloadUrl));
httpRequest.setUnsuccessfulResponseHandler(
new LoggingRequestHandler(
new HttpBackOffUnsuccessfulResponseHandler(backoff)
)
);
httpRequest.setIOExceptionHandler(new HttpBackOffIOExceptionHandler(backoff));
httpRequest.execute().getContent();
From what I can see in the logs, the only headers on this request are accept-encoding and authorization.
The response I get is:
307 Temporary Redirect
cache-control: [no-cache, no-store, max-age=0, must-revalidate]
content-encoding: [gzip]
content-type: [text/html; charset=UTF-8]
date: [Thu, 11 Feb 2021 08:23:51 GMT]
expires: [Mon, 01 Jan 1990 00:00:00 GMT]
location: [https://doc-0c-70-slides.googleusercontent.com/export/al07ue7kob156ds9t1lb1bv2es/r9ibb6n2phn0fv6ekpkl5q005s/1613031830000/108922609109226272057/108922609109226272057/1E3AU3Tf3zB_zp9fs82X5dqjwgn9OjmzFAec_nwxAt4o?id=1E3AU3Tf3zB_zp9fs82X5dqjwgn9OjmzFAec_nwxAt4o&exportFormat=pptx&xoauth_requestor_id=myemail#example.com&dat=ANCXxGiNgFZ2HtpZQgpXbua_7ayLwBdpLeMWK1kQj6EaoYJzqfs9mMlnrkZnuk_3MMj7IMiHZWw4JqhPVjB1EKjjJ8Mnv-DNFCmCr0FZf9UjySxI4LnQDDOvQKxEdnSNaPciQlrFYqsBXlYcWh0PpRVzXWlSHn9KSTe2Tt2wDUp4gT-jLu-GfNYY42b00tUvtbMJ5Wu23jKe_uZrAqy7rxUksdkpbI-UEsuE8D5jLpeEK_8ntJd6wjKWnc50enENMhqiBKCFTD7l3KguteBN4rNUhQZgvTcJOisKEBmJ_7gRLM4AChC6bg1rccvvcJfIe76-Jg0l4OdvSsTE9UnOlCbPWKSyrBpQTqrqRiRrkWhrFr5ZZ62Gw-IJsWkiiltSueEuTsoJZPyqX_SWZgIoCoEQshd7wM-K7_CJYNj27F2pUQf1IB9Rs_KM3GaI3MPP31q3hDrHWr-OLidHihez8HcRkUyn-HlLX7i3EaMRVRqEEfPYLXfypR342WFZveFqpV1OTeG-ctznI6mRSMcCL1BskV_K8Wt4xo08YxwvUXx3YBcYBw7jIbsXn6m_WEFYTIbYJC_Bx-NfIlQfdxGiB2gS6Afnkuz41kU6xpEQY4_LqWRi30fQxxLORyEFsnC3i5yOoDL8PYwv4Q0LX5mBfVpe4BV1EvYjAFWLaZfgNEva8_Q8wNHhBaP6fSsdEqKnYPrI9sRiNGFY23nOTPFcxvNPHHamSBTHHrylYCBI8MSrrQzhTDRZ-LXVlk7NV3lzxTR7RDDGNA]
transfer-encoding: [chunked]
alt-svc: [h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"]
server: [GSE]
x-content-type-options: [nosniff]
pragma: [no-cache]
p3p: [CP="This is not a P3P policy! See g.co/p3phelp for more info."]
x-frame-options: [SAMEORIGIN]
content-security-policy: [base-uri 'self';object-src 'self' blob:;report-uri https://docs.google.com/presentation/cspreport;script-src 'report-sample' 'nonce-5eTqTCwMOyiL5bwXBOSMzQ' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval']
set-cookie: [NID=209=blahblah; expires=Fri, 13-Aug-2021 08:23:50 GMT; path=/; domain=.google.com; HttpOnly]
x-xss-protection: [1; mode=block]
After that, the Google Drive SDK (well, it's underlying HttpTransport class) follows this redirect, using the value from the location header as the request URL. The response I get then is 413 Request Entity Too Large.
I'm receiving invalid characters on try to receiving JSON by http protocol in C.
When I send
GET /<query> http/1.1\r\nHost:<host>\r\n\r\n
then the result displays as follow:
HTTP/1.0 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: false
X-Content-Type-Options: nosniff
Date: Sun, 07 Dec 2014 13:14:29 GMT
Content-Length: 11410
�
I don't know why I don't receiving JSON? However, in browser's address bar I type the same query & I received the json as well.
[UPDATE # 1]
I found it useful to work on built-in library, as the error is related to network byte compressions so I used Qt's library QNetworkManager specifically to done this job.
Please use a HTTP library or make yourself comfortable with the HTTP protocol and implement it properly.
Content-Encoding: gzip
At least this line means trouble for your simple parsing. But interestingly, based on your request the server should not sent this line if a non-compressed version is available. This means not only your code is buggy, but that the server might be buggy too (it actually assume that you understand any compressions because you did not say different).
GET / http/1.1\r\nHost:\r\n\r\n
And your request is wrong too. It must be HTTP/1.1 instead of http/1.1. And it must contain a proper host header.
Qt's QNetworkManager is best for this purpose, as it do all the intricate stuff itself & provide elegant interface to user.
I'm converting a Web Api project to service stack and in json responses I'm getting an extra line of text before and after the json content. I'm using fiddler to capture the response.
Edited for brevity, here is an example:
18d
[{"id": ... }]
0
What are these lines? I can't find any configuration option that would seem to correspond to keep this from happening.
Edit
I went back and started with the basic hello service stack example, and here's what I got for a response:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Server: Microsoft-HTTPAPI/1.0
X-Powered-By: ServiceStack/3.943 Win32NT/.NET
Date: Thu, 18 Apr 2013 15:48:49 GMT
1b
{"Result":"Hello, JRandom"}
0
I'm assuming the extra response lines are the result of the Transfer-Encoding: chunked header.
Im starting experimenting with Wikimedia, but I somehow can't get the login request working with a HTTP Client (RESTClient Firefox and others). This should be fairly simple, but it seems to fail or I have overlooked something evident.
I am using the instructions from this site.
This is what I insert in RESTClient:
I don't get the MediaWiki API Result back, but the help page (see below).
What am I doing wrong here? Thanks for any input.
Status Code: 200 OK
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 38052
Content-Type: text/html; charset=utf-8
Date: Mon, 09 Jul 2012 11:50:51 GMT
MediaWiki-API-Error: help
Server: Apache
Vary: Accept-Encoding
X-Cache: MISS from sq33.wikimedia.org, MISS from amssq35.esams.wikimedia.org, MISS from amssq39.esams.wikimedia.org
X-Cache-Lookup: MISS from sq33.wikimedia.org:3128, MISS from amssq35.esams.wikimedia.org:3128, MISS from amssq39.esams.wikimedia.org:80
X-Content-Type-Options: nosniff
<!DOCTYPE HTML>
<html>
<head>
<title>MediaWiki API</title>
</head>
<body>
<pre>
<span style="color:blue;"><?xml version="1.0"?></span>
<span style="color:blue;"><api servedby="mw67"></span>
<span style="color:blue;"><error code="help" info=""
xml:space="preserve"></span>
The are two problems with your request:
You're using the wrong URL. The correct domain is en.wikipedia.org, not www.wikipedia.org.
It seems RESTClient is using the Content-Type of text/plain by default, but the API expects application/x-www-form-urlencoded.
If you correct those two problems, you will get the correct response.
You also might want to indicate in what format do you want the response, by adding format=xml or format=json to the request. The default is HTML-formatted XML, which is useful for showing in a browser, but not for consumption by your application.
Is there a way in htaccess to ensure the headers for my json are correct?
Update: Does anyone see anything wrong with these headers for json?
Date Mon, 26 Jul 2010 08:31:11 GMT
Server Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.7a mod_fcgid/2.3.5 Phusion_Passenger/2.2.15 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By PHP/5.2.13
X-Pingback http://brettbarros.com/wordpress/xmlrpc.php
Content-Disposition attachment; filename="json_api.json"
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 719
Keep-Alive timeout=5, max=98
Connection Keep-Alive
Content-Type application/json; charset=UTF-8
Specifically, it's working with jquery's getJSON in ie8, ffx, chrome, but not ie7 or ie6...
AddType application/json .json
is a simple way to make all your *.json files being sent with the correct mime type. That, of course, doesn't work, if you create them dynamically in something like a, say, PHP script. In that case, you can add the info inside the script:
<?php
header('Content-Type: application/json');
// ...
You can inspect the headers sent along from the server side using Firebug's Net tab. It shows all the headers for both the request and the response.
Make sure the Content-Type is application/json. You can inspect the http headers with wget and whatnot if you aren't sure what they are.