I'm building a REST API.. Sometimes the server returns the response with chunked transfer encoding? Why is that?!
Why can't the server always return the response in the same encoding?
The problem is that I don't know how to read the data when its returned as chunked!?
update
neeed moore downvotes... to breeeath...
Assuming your server is using Apache, this is expected behaviour. You can disable it by putting this line in your .htaccess file:
SetEnv downgrade-1.0
However, you should consider modifying your reading code to just support different content encodings. What library are you using to make the HTTP request? Any reasonable HTTP library can handle chunked requests. If your requesting code is written in PHP, use curl. http://php.net/manual/en/book.curl.php
Taken from Server Fault:
specify the "Content-Length' header, so server knows, what's the size of the response
use HTTP 1.0 at the requester's side
A problem may be that Apache is gzipping your download, taking care of correcting the Content-Length, or in your case, adding the header
Content-Encoding: chunked
You can add a .htaccess RewriteRule to disable gzip:
RewriteRule . - [E=no-gzip:1]
Related
I'm building a REST API.. Sometimes the server returns the response with chunked transfer encoding? Why is that?!
Why can't the server always return the response in the same encoding?
The problem is that I don't know how to read the data when its returned as chunked!?
update
neeed moore downvotes... to breeeath...
Assuming your server is using Apache, this is expected behaviour. You can disable it by putting this line in your .htaccess file:
SetEnv downgrade-1.0
However, you should consider modifying your reading code to just support different content encodings. What library are you using to make the HTTP request? Any reasonable HTTP library can handle chunked requests. If your requesting code is written in PHP, use curl. http://php.net/manual/en/book.curl.php
Taken from Server Fault:
specify the "Content-Length' header, so server knows, what's the size of the response
use HTTP 1.0 at the requester's side
A problem may be that Apache is gzipping your download, taking care of correcting the Content-Length, or in your case, adding the header
Content-Encoding: chunked
You can add a .htaccess RewriteRule to disable gzip:
RewriteRule . - [E=no-gzip:1]
I am using AFNetworking library in my projects. recently I heard about gzip data compression which is given by defalut in NSURLConnection Class and reducing the time and loading time of large json response, hence AFNetworking might have that feature as it is working on top of NSURLConnection.
but I do not know how to get gzip compressed json response from php API through AFNetworking.
I need this technique when Json response file size is more that 100kb+.
If server supports gzip it could require client to ask server to respond with gzip enabled. To ask server to use gzip you add specific "Accept-Encoding" header to your requests. You can do this, for example, with this lines of code:
// Get one that serializes your requests,
// for example from your AFHTTPSessionManager subclass
AFHTTPRequestSerializer <AFURLRequestSerialization> *requestSerializer = ...
[requestSerializer setValue:#"gzip, identity" forHTTPHeaderField:#"Accept-Encoding"];
"Accept-Encoding" header must contain gzip while, probably, identity is not required.
If you are using NSURLSession based API in AFNetworking, it would be included automatically as said here. Thus you don't need to do anything.
Please be noted that you may not see the header value in the app log for request, but you may check the header in response to confirm this behaviour if the server supports gzip.
Background
Part of my application's responsibility is handling requests for static resources (CSS, JavaScript, images) in a controlled manner. Based on some application logic, it will return one from a selection of different files that might be served on that URL at different times and to different users. These are therefore static files, but delivered in a dynamic way.
The application is based on Symfony Components and the serving of these static-ish files is handled by the BinaryFileResponse class.
The bootstrap code calls the trustXSendfileTypeHeader method:
\Symfony\Component\HttpFoundation\BinaryFileResponse::trustXSendfileTypeHeader();
The application uses some internal logic based on configuration and the detection and use of apache_get_modules() to determine availability. If XSendfile is available and the configuration says to use it, it sets the X-Sendfile-Type header:
if ($useHeader === true) {
$request->headers->set('X-Sendfile-Type', $header);
}
$response = new BinaryFileResponse($filename);
Problem
When I run this with the configuration set to never use XSendfile, or through the PHP built-in web server, which obviously does not support XSendfile, everything is perfect.
When I utilise XSendfile, it also works -- most of the time.
Every so often, typically if I press the f5 key 3-4 times in quick succession, "something" wigs out and I get a garbled response. For example, this is supposed to be a JavaScript file (copied from "Response" tab under "Net" in Firebug):
hxYîãx��HTTP/1.1 200 OK Date: Tue, 05 Feb 2013 14:49:10 GMT Server:
Apache/2.2.22 (Ubuntu) X-Powered-By: PHP/5.4.6-1ubuntu1.1
Cache-Control: public Last-Modified: Tue, 29 Jan 2013 13:33:23 GMT
Accept-Ranges: bytes Content-Transfer-Encoding: binary ETag:
"10426f-9f6-0" Vary: Accept-Encoding Content-Encoding: gzip
Content-Length: 1011 Keep-Alive: timeout=5, max=98 Connection:
Keep-Alive Content-Type: application/javascript
������VmoÛ6þ,ÿkÀ²ãIý°~q [Üt]
XÑt¶H¤#Rv¼Àÿ}w(YSÀØ2yïå¹*¾Á>¯¥¥,è) Æ^Ât¸BaÆ\éjgäjí
Î&ð*¸Åí¸tY!³Ç$Óe"jÞ![#,n®®oï®A¨þ¸þù××Þ©¼¼ôÇêÚd¹49mv°ÔrtBÖ^;WÍÓÔg´Y¥´FéôÁR9o°35Îà^º´N=UÐèEµ¢XE¸íÒ%ª°¨Úò7¬KñT¾{;£ÈrTnß³étUè{QÀçÍn·:'üJëQÍÄËZeNjOàyÕÁ:#3wö~4Òét1ù$µeN)RD|
¶FTØJ·ß½¥¨¸õGç >9TyÜxzgl-J:) b«9ûAQ½KXÉ!yÐÓ]
óÆÎ#W¡?¢vún·7j©ÿ¢ðõÖGEÁy\ºp¤÷cKxf?ï*¼Éç0^ïîÌÇ°ñDQ¸mYJ|4t¾ñæËÛ¯Å
¨6:çøp(}þÑò|LÂ;Õ(#v¹* /[¨U|xª
æ]ÍyìjµòÛ¯p?4sI¥"v÷ôp|uQ4ò4&Ï·$eÒc¸ xo%7Ôi´2ñx;TuÙj23 áÊ%ħ¿¹lÌwÀS.&ÏØß7¸}ó
ZXzå k2'Zdùè
�¦ºû-Ù[Ó²ÿU(¯¤¥=pÃjô¾ç]]Øhhô²×ÙãÚÍ4¨[!Õ}'Òþ^Ð�ûxÿ#+ÚVÞ~áÌáy?d
aíD¹·U×ÃÚ] õ5íÃø¨o÷ÂAvUÆmÍaày`¦ä©A?mL[-}®(ÿË
d°öò¬}Ç¢³Çp1À^6%0 hTô^ts´ÞíWô
fO¶ö¢ÎNÜæ·HîUôÔ¶±ÌCµsxh.9åçi Û·_ÈÞØ_ÄãY_Ö}G<ì°ý2wÔ¿aw8/þù\ã±þ"0C
oÂh'tE¶À¤¥7I½éßRt.s?á^d|k/Æ)wRw÷cG¿<Þ
¼´°/^ø*ʤAVZ×y¿zÅΪ¥[²Õ1ò_Vµæï_YXÁÕö ��YXÁÕö ��
Note the presence of the headers in the response body, and the rest of it which is clearly not JavaScript. There are also some spurious characters at the start, which possibly is what leads to the headers being pushed to the body. I have tried to determine if this content is the result of gzipping, but I can't confirm that yet. (See also update below)
Question
Firstly, is BinaryFileResponse even the correct class to use for serving text (non-binary) files? The documentation for the class only says "BinaryFileResponse represents an HTTP response delivering a file." This isn't very detailed but it doesn't say anything about it being exclusively for "binary" files. However the name has its own implications, why didn't Fabien just call this class FileResponse?
Secondly, and more importantly, what could be causing this? I don't believe it is a browser issue because it is repeatable in both Firefox and Chrome. Is this a bug in the XSendfile module or in the BinaryFileResponse class perhaps? (I am likely to think it is not the former because I have used it before in a more "raw" way not via Symfony Components, with no such issues).
Has anyone else experienced this? Any idea where I should even start looking to track this down? I've looked at the BinaryResponseFile source code but it doesn't really do much with XSendfile, just sets the relevant header and prevents content in the response body, from what I can see.
Update
I've just noticed a couple of things about these garbled responses:
There are no actual headers being sent at all, i.e. on the "Headers" tab in Firebug, for the garbled responses, it only lists Request headers and doesn't even show the heading for Response headers.
Even if I set some custom header on the Response in PHP, that header does not appear at all in the garbled responses (as a header or in the response body), but the custom headers appear correctly for the responses that aren't broken.
First, let me say that I don't have any experience with this Apache module, but I'll try to guide you through a general error deduction:
You should check if you can reproduce it more reliably. While a web browser might be ok to try it out, you should go for something like curl and do the request multiple times, for example using a bash for-loop.
for i in `seq 1 5`; do curl -v http://localhost/xsendfile-url; done
The fact that the Connection: Keep-Alive header is set and that there are some weird characters before the actual HTTP header lead me to believe that you won't be able to reproduce this problem with separated curl calls, because it will open a fresh connection each time. So try this to check if that gives you the weird behavior (curl has keep alive on by default):
curl -v http://localhost/xsendfile-url http://localhost/xsendfile-url http://localhost/xsendfile-url
Using this, you could go to the projects github issue page and report your findings. Most probably they will there help you in telling you why mod_xsendfile is behaving the way it is or that you have found a bug.
I have a page that calls a php script. On MAMP everything works fine but when I upload it to a server I get the following error:
Call Request failed! Status code: 4000
Reason - Caught an HttpRequestValidationException due to some bad characters in the request. Make sure your post request is encoded as xml, preferable as UTF-8 ('Content-Type: text/xml; charset=utf-8'). Exception: A potentially dangerous Request.Form value was detected from the client (<?xml version="..."utf-8"?> <uclassify xmlns="ht...").
Has anyone seen anything like that?
you can check it yourself here just place a word like php or ios
It looks like your server is validating based on the content-type header. It seems to want text/xml, whereas you are sending application/x-www-form-urlencoded (which is the default for $.ajax).
Try explicitly setting the content type to text/xml in your $.ajax call. (reference)
try changing charset=utf-8 to charset=UTF-8
Yesterday , I asked a question about socket post file data to php page.
Link is here
Upload and POST file to PHP page
When I follow the way , I changed my code.
char *str="POST /path/upload_file.php HTTP/1.0 \n Host: 00.00.00.00 \n Content-Disposition: name=2.jpg;filename=2.jpg\r " ;
write(sockfd, buf, filestat.st_size);
sprintf(send1,"%s%s\r\n",str,buf);
retval= send(sockfd,send1,sizeof(send1),0);
When I execute the Program , can get
result:
501 Method Not Implemented
Method Not Implemented
to /index.html not supported.
Invalid method in request
Apache/1.3.39 Server at localhost Port 80
I guess it's possible :
1. apache can't support something?
(my apache don't support ssl)
2. http protocol is not details?
3. other?
Thanks a lot.
There are multiple issues with your code.
First, the Host header is part of the HTTP 1.1 specification, and does not apply to HTTP 1.0.
Second, the delimiter for separating headers as well as body is \r\n, not \n.
Third, you are using the Content-Disposition in a request, the way it should be used in a response.
Lastly, you need to send the request as multipart/form-data. The answer you've linked to had it right. The request has to respect that format.
I've written a detailed example not so long ago (although in PHP, but the request format stays the same). You can find it here.