I'm using Xampp and Perl , when I try to set a cookie with CGI::Cookies or CGI::Session it prints the cookies data to the browser page instead of setting the cookie.
Example:
my $session = new CGI::Session();
my $cookie = CGI::Cookie->new(-name=>$session->name, -value=>$session->id);
print $session->header(-cookie=>$cookie, #_);
Result on the browser screen:
Set-Cookie: CGISESSID=cebc22d8046879efa9d0216eb8995d13; path=/
Date: Thu, 20 Feb 2014 04:34:22 GMT
Content-Type: text/html; charset=ISO-8859-1
It looks like that you had sent the header to the browser already.
After the standard header received by browser it handles every output as text.
Regards,
Related
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.
On a page of a website we're building http://ovsd.nutrislice.com/wellness/ , pdf download links ("Download the Issue") get stuck while loading in Chrome's PDF Viewer but work in all other browsers by triggering a download. Right click + "Save as" works in Chrome. I realize Chrome is the only browser with a built-in, default pdf viewer.
I figure we can instruct people to right click and then "save as", but I wanted to see if anyone can see a problem with either the html, or in the server response, which would cause chrome to fail like that.
Its not a traditional pass-thru file download sitting on a server somewhere. We use Heroku, and I'm currently storing the pdf's in the DB (I realize the downsides of this, but it was a simpler system than managing off-site files on S3 for now). I'm generating the response dynamically via a Django View, so I wonder if there's something i'm missing in the response headers or something.
Thanks!
Looks like a bad content-type:
Content-Type:('application/pdf', None)
Check your code where you are assigning a content-type to the response. Looks like you're sending a tuple instead of just application/pdf.
Like #dgel mentioned, your content type is incorrect:
$ curl -I http://ovsd.nutrislice.com/dbfiles/cms/resources/Vol5_Issue1_5_Dos_and_Donts_for_Supermarket_Survival.pdf
HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST,GET,OPTIONS,PUT,DELETE
Access-Control-Allow-Origin: *
Cache-Control: max-age=90000
Content-Type: ('application/pdf', None) # <- Incorrect
Date: Fri, 09 Nov 2012 19:25:06 GMT
Expires: Fri, 09 Nov 2012 23:20:28 GMT
Last-Modified: Thu, 08 Nov 2012 22:20:28 GMT
Server: gunicorn/0.14.6
Connection: keep-alive
Also it might be a good idea to add Content-Length 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.
I'm working on a JSON API and I want to do something like Facebook's opengraph styling.
The opengraph style indents and breaks lines, how do you go about doing this? If you use styling through HTML or CSS the JSON can not be loaded.
You can use JSON_PRETTY_PRINT which is new in PHP 5.4:
<?php
// Facebook sends a Content-Type of text/javascript
// So I assume you want to too, but you may prefer
// application/json
header('Content-Type: text/javascript');
echo json_encode($data, JSON_PRETTY_PRINT);
?>
If you don't have, or can't upgrade to version 5.4 then you have to find some side of server-side parser.
Edit
I don't know why I assumed you're using PHP when you haven't tagged it. Whatever server side language you're using though you'll want to send out a non-html Content-Type and use new lines and tabs to pretty print it, not HTML.
facebook appear to be using browser detection to format the JSON on the server.
for wget, no formatting is applied:
> wget -q -S -O - http://graph.facebook.com/4
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Type: text/javascript; charset=UTF-8
ETag: "539feb8aee5c3d20a2ebacd02db380b27243b255"
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Pragma: no-cache
X-FB-Rev: 526949
Set-Cookie: datr=imJrT4lrhBZ48Mrtw4uYfByk; expires=Sat, 22-Mar-2014 17:34:02 GMT; path=/; domain=.facebook.com; httponly
X-FB-Debug: +gpBLnliDoRvuNtlHIwHASwsDz4pJm9TP3btrrw6AsE=
X-Cnection: close
Date: Thu, 22 Mar 2012 17:34:02 GMT
Content-Length: 172
{"id":"4","name":"Mark Zuckerberg","first_name":"Mark","last_name":"Zuckerberg","link":"http:\/\/www.facebook.com\/zuck","username":"zuck","gender":"male","locale":"en_US"}
but for google chrome, wireshark shows text formatted with spaces and newlines:
{
"id": "4",
"name": "Mark Zuckerberg",
"first_name": "Mark",
"last_name": "Zuckerberg",
"link": "http://www.facebook.com/zuck",
"username": "zuck",
"gender": "male",
"locale": "en_US"
}
(it really is different data - the Content-Length is 210 in this case). note that Content-Type is still text/javascript - they are not rendering into HTML.
so you'd need to use a JSON formatter for whatever language you are using (i guess you are already using a library, so check whether it has a "prettyprint" option or similar). plus, if you want to save bandwidth when formatting seems unimportant, browser (and general context - see Paul's comment) detection from request headers.
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.