I am actually getting an Ajax Response Text from a PHP Server. Suppose the response text comprises of 20 characters.
(e.g. echo "asdhfgyd dhrjtjsjtjr";)
This equals roughly (20/1024) KB.
I'm using a mobile web application to get this reponse text using standard Ajax XMLHttpRequest. However when i measure the data usage by the mobile app due to only that one single ajax response text, it uses nearly 3 KB. This is what i'm not understanding, what is causing this additional data usage, can you please help me out on this.
Additionaly: I confirm that this is the only part of the app that makes internet usage, the others are offline features.
The data you see in the response text is only the body of the response. The other bytes will most likely have been taken up by the headers.
For example here is a response I would expect to receive when calling an API:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?XFxwc2ZcSG9tZVxEb2N1bWVudHNcR2l0SHViXFNvdXJjZVxDaGVyaXNoQXF00XJpc2guQXBpXGFwaVxjaGlsZFxsaXN0?=
X-Powered-By: ASP.NET
Date: Fri, 13 Mar 2015 09:02:35 GMT
Content-Length: 577
[{"result":"FooBar"}]
Related
I'm use urllib craw a https web,
the response_header are:
HTTP/1.1 200 OK
Cache-Control: max-age=0
Content-type: application/octet-stream
Transfer-Encoding: chunked
Date: Wed, 07 Nov 2018 07:01:00 GMT
Server: lighttpd
response data are:
response data
The web display are:
response display
I know the content type application/octet-stream are not general encoding,but there must be some web js decode those response data,Does anyone know how to find the decode code from the web js or find out which web js file use the response data
I'm implementing static file serving in node.js for learning and fun. Let's say I am sending a file called party-time.txt which is:
100 bytes uncompressed
70 bytes gzipped
If the user requests Range: bytes=-10, is this request for the last 10 uncompressed bytes (e.g., 91-100) or is it the last 10 compressed bytes (e.g., 61-70)?
HTTP retrieval requests using conditional or unconditional GET methods MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request.
14.35.2 Range Retrieval Requests
Because the actual entity returned from the request is the gzip encoded data, that data is used to derive the Content-Length and therefore the Range is applied against that.
As part of the HTTP protocol, you should be specifying the Content-Encoding as well as the Content-Length. The content length should match the length of the file relative to your encoding technique. For example, if you set your Content-Encoding to gzip, the range of bytes that the user requests should be a request for the compressed length.
Packet example:
HTTP/1.1 200 OK
Date: mon, 28 Aug 2015 22:38:34 GMT
Server: <Your server>
Last-Modified: mon, 28 Aug 2015 22:38:34 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
An xml-file is loaded from a different domain within an iframe in a Webkit/Chrome browser and the HTTP Content-Type is set to application/xml.
Generally xml would be colored and pretty-printed, using a built-in browser content-script. In the iframe, the same xml-file will only show the text within the tags and no colored outline, as would be expected with browser-scripts turned off.
Browser:
Iframe:
(different content)
Response headers:
HTTP/1.1 200 OK
Date: Thu, 29 Aug 2013 08:52:55 GMT
Server: Apache
Vary: Cookie
Content-Length: 154
Keep-Alive: timeout=15, max=10000
Connection: Keep-Alive
Content-Type: application/xml
Adding Access-Control-Allow-Origin:* to the response-header didn't change anything.
Update: HTML:
<form id="api_output" target="iframepostform" action="https://example.com/api/"
method="POST" accept-charset="utf-8">....
<button type="submit">Send</button>
</form>
<iframe class="clearfix" src="" name="iframepostform"
id="iframepostform" seamless="seamless"></iframe>
What is the simplest solution to fix this, without abandoning iframes and resorting to XHR requests?
Use Yahoo Pipes or YQL as a proxy formatter service. Here are some examples:
How to get the formatted view of YQL as result?
Yahoo Pipes to enrich RSS descriptions dynamically with ${title} variable?
(Note: This is a follow up to my question Can jQuery.getJSON put a domain's cookies in the header of the request it makes? and covers the XSS case of Setting a cookie in an AJAX request?)
I've been told I'm unable to set cookies to be read by other domains that are not subdomains of the current domain using $.cookie(..., ..., {domain: ...}). But in a comment on a response to my last question, #zanlok said "The server's reply, however, can definitely set a cookie" and it got two upvotes.
So I thought I'd try using a service which was created for the explicit purpose of setting cookies called Freebase's "touch" API. The call looks like:
$.getJSON("http://api.sandbox-freebase.com/api/service/touch",
{}, // URL parameters
afterCookieIsSetCallback); // Callback function
Looking in FireBug at the response header it's like this:
Date Wed, 24 Nov 2010 03:35:28 GMT
Server Apache
X-Metaweb-Cost [...]
Etag [...]
Expires Wed, 24 Nov 2010 03:35:29 GMT
Cache-Control no-store
Vary Accept-Encoding
Content-Encoding gzip
Set-Cookie mwLastWriteTime=1290569730|10325_9202a8c04000641f80000000199eff96|sandbox; expires=Thu, 25-Nov-2010 03:35:28 GMT; Path=/
Last-Modified Wed, 24 Nov 2010 03:35:28 GMT
Content-Length 134
Content-Type text/plain; charset=utf-8
X-Cache MISS from cache01.sandbox.sjc1.metaweb.com
Connection keep-alive
X-Metaweb-TID cache;cache01.sandbox.sjc1:8101;2010-11-24T03:35:28Z;0001
So there's definitely a Set-Cookie in there, and the script runs the response handler. Yet the cookie is not present in the request headers for later JSON requests this script makes to .sandbox-freebase.com.
(By contrast, simply typing the touch api URL into the address bar and loading it that way does set the cookie for future requests. That applies even in other tabs.)
This seems to be a deviation from a prior "expected behavior", because there was a toolkit published by MetaWeb circa "2007-2009" which seemed to think such an approach could work:
http://www.google.com/codesearch/p?hl=en#v099O4eZ5cA/trunk/src/freebase/api.js&q=touch%20package:http://mjt%5C.googlecode%5C.com&l=340
Without knowing much about it, I'm wondering if it was a recent change that Firefox adopted and then WebKit followed suit. Perhaps the one mentioned here:
http://trac.webkit.org/browser/trunk/WebCore/xml/XMLHttpRequest.cpp#L856
So is there any canonical documentation on this particular issue?
The AJAX call you are making, is making a request to a domain outside of the domain of the top level url(the url in the address bar). This results in it being a 3rd party cookie, by default Internet explorer won't persist a 3rd party cookie. Meaning that the cookie will come back in the Set-Cookie header on the first request, but subsequent requests that you make to that server will not have that cookie sent in the request.
Like you said, if you go directly to the url in your browser it works. This is because in this case it's a first party cookie.
In order for IE to accept 3rd party cookie's the server that is sending the SET-COOKIE header on it's response, must also have a P3P Policy Header set.
Here is an example, when you navigate to CNN, you will notice one of the requests it makes is to a domain name of b.scorecardresearch.com, scorecardresearch is dropping a tracking cookie, but this cookie is considered a 3rd party cookie. So in order to make it work they had to also in include a p3p header, see headers below:
HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Date: Thu, 02 Dec 2010 19:57:16 GMT
Connection: keep-alive
Set-Cookie: UID=133a68a4-63.217.184.91-1288107038; expires=Sat, 01-Dec-2012 19:57:16 GMT; path=/; domain=.scorecardresearch.com
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, no-cache, no-cache=Set-Cookie, no-store, proxy-revalidate
Server: CS
If you were to copy this header and add it to the response, you would notice that the cookie's start working,
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
It's best that you craft a P3P header specific for your business, but the above should work for testing purposes.
If I correctly understand you, you are wondering why the server sends Set-Cookie only on the first request. If that is true, then it's by design - take a look here:
http://en.wikipedia.org/wiki/HTTP_cookie
Set-Cookie is like a setter - the server sends it for the browser to cache it locally. It can send every time, but there is no need to do that, so it will send it again only if it needs to change the value stored locally.
Browser, on the other hand, will send Cookie header every time with the contents set by the last issued Set-Cookie from the server.
Hi my problem is a bit wired:
my $.ajax success handler looks like:
function(data){
alert(data);
}
Pretty simple, yeah?
The problem is that data IS ALWAYS 3 character long - no matter what was sent by the server! The characters: 31 65535 8 (using charCodeAt()).
In other browsers (even in IE 8) all works fine.
I've looked at xhr.responseText in complete handler - just the same result.
UPDATE
Full http response
HTTP/1.1 200 OK
Date: Sun, 07 Feb 2010 13:35:39 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.2.10-2ubuntu6.4
Set-Cookie: 1111111111111111=UjVXb1Q3WTdUIQ8jXmALbA88VzpRcVcgBzMDcldyUmtWawAyAFpQP1IwASEAbFh%2FDjoLZ1RiBWlWdwBnUGMHZlU2UGBTZFA5B2UMMlJgC29SbVdjVDRZOVRsDzReaQtuDzpXZVFjV2UHYwM1VzNSNlYzAG4AMVAwUjUBIQBsWH8OOgtlVGAFaVZ3AD5QIgdcVWVQNlNhUHIHMAwjUiQLL1JvVyZUOVk8VGkPal54C2wPNVcyUX1XYgdgAzlXL1IzVioAbQA3UG9SdgE4ACRYNg4xC2RUagVxViAAJFA3B3FVW1AzU2JQZQc7DCRSdQs2UidXb1Q2WT1UYA9yXhcLMg92V2lRP1c%2FBzcDLlc1UixWNAB8AC1QNVI7AW4AJ1htDnQLPVQyBT9WMABsUHIHTlVXUBtTQFAgB20MflJnCzZSdFcCVGpZY1Q%2BDz9eLQsuDyxXTlEHV3MHYAMvVzBSOVYmAGcAdlBsUmUBMABtWC4ObAs1VCMFJ1YKADZQMQd3VW1QJFNsUHQHLAxyUmwLflJuV2RUM1k3VHgPYV5oC2sPOVc1UWdXagdgAzBXOVIgVj8AIQ%3D%3D; expires=Tue, 07-Feb-2012 13:35:39 GMT; path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 21
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
1
UPDATE !
Well, problem temporary? solved by disabling gzip in .htaccess
The characters you get look weird, but could it be that it's a BOM? It's none of the ones listed in the article, but maybe getCharCode() gets something wrong.
In that case, you would have to check the script you call to request the data. Try saving it explicitly without a BOM.
this is most times an problem with propper encoding of the requested content / displayed content.
Please verify that both use the same format.
Despite ajax is always done in UTF-8 some implementations are weird and they don't allow passing non ascii characters. You have to change them to entities.
If You pass only one character and still get problems - It might be the BOM mentioned by Pekka. You would have to save Your PHP FILE without any spaces before
Second thing is that You might be outputing something at the end of the php file.