net::ERR_INCOMPLETE_CHUNKED_ENCODING with OPTIONS request - php

I'm using nginx (1.9.3) + php-fpm (via unix sockets) with another nginx as a reverse proxy. And rarely (1 out of ~100 requests) I get net::ERR_INCOMPLETE_CHUNKED_ENCODING during OPTIONS XHR request from one subdomain to another (cloud.example.com to api.example.com). This OPTIONS request sent automatically before POST. Chrome Version 50.0.2661.94 (64-bit) OS X
Reverse proxy:
location / {
proxy_pass http://xxx.xxx.xxx.xxx:80;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
proxy_buffering off;
}
Request headers:
OPTIONS /my/request/uri HTTP/1.1
Host: api.example.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: https://subdomain.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: https://subdomain.example.com/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Response headers:
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 13 May 2016 06:39:05 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: https://subdomain.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type
Content-Encoding: gzip
Strict-Transport-Security: max-age=31536000; includeSubdomains;
My guess is that this could be caused by timeouts, but I doubt there are milliseconds timeouts somewhere. The screenshot below is from a Chrome developer tools network tab filtered by the same request repeated many times.
Any help is much appreciated!

Related

HTTP416 with Laravel/Excel

Since my hosting provider has switched to HTTP2 I am getting a HTTP 416 Range Not Satisfiable error when trying to export data to Excel OR pdf formats. What I've tried already:
adding RequestHeader unset Range to .htaccess
adding Header unset Accept-Range to .htaccess
setting Cache-Control headers expiration to 0
I've talked to the technical support of my hosting provider and whatever they've doing for the next 20 minutes didn't work either. I think they even tried to switch off HTTP2 for my account – however the error persisted.
What I find even more bizarre is the fact that the error comes before the logs have been written, meaning that the file has not been generated at that point at all. It seems like the request comes to the server and bounces back with 416 without actually launching any process in the first place. Any ideas what it could be? I have not touched the code in the last 2 weeks and it seems to have been working alright.
Here are the request headers
:authority: [....xxx].com
:method: POST
:path: /v1/reports/shifts/export
:scheme: https
accept: application/json
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,de;q=0.8,ru;q=0.7,be;q=0.6,pl;q=0.5,fr;q=0.4
authorization: Bearer: eyJ0eXAiOiJKV1QiLCJhbGc....
cache-control: no-cache
content-length: 132
content-type: application/json
origin: https://[....xxx].com
pragma: no-cache
referer: https://[....xxx].com
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36
and here are the headers coming back with HTTP416 response
accept-ranges: none
access-control-allow-headers: Origin,X-Requested-With,Content-Type,Accept,Authorization,Accept-Language,Content-Language,Last-Event-ID,X-HTTP-Method-Override
access-control-allow-methods: GET, PATCH, POST, PUT, DELETE, OPTIONS
access-control-allow-origin: https://[....xxx].com
access-control-request-headers: X-Requested-With
cache-control: public
content-disposition: attachment; filename=shift.xls
content-length: 0
content-range: bytes */6144
content-type: application/vnd.ms-excel
date: Fri, 27 May 2022 11:54:20 GMT
last-modified: Fri, 27 May 2022 11:54:20 GMT
server: nginx
vary: Authorization
Any ideas?

A combination of a specific WordPress plugin + Modsecurity is causing 500 Internal Server Error

I'm using one of the WooCommerce Appointment plugin and it's causing a 500 internal error.
It seems the Modsecurity intercepts the http access but I don't know what's wrong in the following log.
--a7316b05-A-- [02/Dec/2020:01:37:02 +0800] X8Z-PAqMAA4AAAp171YAAAAE 210.242.3.205 53878 10.140.0.14 443
--a7316b05-B-- GET /wp-admin/admin.php?post_type=wc_appointment&page=appointment_calendar&calendar_month=12&view=month&tab=calendar&filter_appointable_product=&filter_appointable_staff=&calendar_month=11&calendar_year=2020
HTTP/1.1 Host: homie.tw Connection: keep-alive
Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel
Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/86.0.4240.198 Safari/537.36 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate Sec-Fetch-User:
?1 Sec-Fetch-Dest: document Referer:
https://homie.tw/wp-admin/admin.php?page=appointment_calendar&calendar_year=2020&calendar_month=12&view=month
Accept-Encoding: gzip, deflate, br Accept-Language:
zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7,ja;q=0.6,zh-CN;q=0.5 Cookie:
wordpress_sec_39c5768458d20eee442b5f013f95c6e4=chihao.weng%40gmail.com%7C1606879569%7CIYBGng45F7DiEjkIlD5y2rCpJPu7QdupcJsax3TNQmT%7C99241b7eeb1b6d93b810479b22b84ecc4ff13e5394d5798b59840f4f759f649d;
mp_a36067b00a263cce0299cfd960e26ecf_mixpanel=%7B%22distinct_id%22%3A%20%221736f1935d51cd-0a84c5198fb224-31617402-fa000-1736f1935d6df1%22%2C%22%24device_id%22%3A%20%221736f1935d51cd-0a84c5198fb224-31617402-fa000-1736f1935d6df1%22%2C%22%24initial_referrer%22%3A%20%22https%3A%2F%2Fhomie.tw%2Fwp-admin%2Fplugins.php%22%2C%22%24initial_referring_domain%22%3A%20%22homie.tw%22%7D;
_ga=GA1.2.332580245.1599972620; energyplus-u=8d66286c0cdf0413991242985d297257;
wordpress_test_cookie=WP%20Cookie%20check;
tk_ai=woo%3ADAEy5asYphPD0Q3i1p5KUhdQ;
woocommerce_recently_viewed=1106%7C1433%7C1104%7C1105%7C1103%7C1101;
wordpress_logged_in_39c5768458d20eee442b5f013f95c6e4=chihao.weng%40gmail.com%7C1606879569%7CIYBGng45F7DiEjkIlD5y2rCpJPu7QdupcJsax3TNQmT%7C0af3928e6a5cc78caf2d4fc871526abac2817b1604d085a887e9f81a7bc76fe2;
wp-settings-1=libraryContent%3Dbrowse%26editor%3Dtinymce%26hidetb%3D1;
wp-settings-time-1=1606706772; woocommerce_items_in_cart=1;
woocommerce_cart_hash=0737a3efd621083e63e459451c8eb2b8;
wp_woocommerce_session_39c5768458d20eee442b5f013f95c6e4=1%7C%7C1606879577%7C%7C1606875977%7C%7Cf29b691703754018bf8562fa8f40249c
--a7316b05-F-- HTTP/1.1 500 Internal Server Error Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0
X-Frame-Options: SAMEORIGIN Referrer-Policy:
strict-origin-when-cross-origin Content-Length: 2789 Connection: close
Content-Type: text/html; charset=UTF-8
--a7316b05-H-- Apache-Handler: application/x-httpd-php Stopwatch: 1606844220929440 1447814 (- - -) Stopwatch2: 1606844220929440 1447814;
combined=9964, p1=429, p2=8091, p3=65, p4=1265, p5=113, sr=13, sw=1,
l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity
for Apache/2.9.1 (http://www.modsecurity.org/); OWASP_CRS/3.2.0.
Server: Apache Engine-Mode: "ENABLED"
--a7316b05-Z--

NGINX and PHP Gzip compression not working in browser but works in cURL

There is a peculiar issue happening in my NGinx and PHP Setup.
My Test URL : http://104.194.26.13:2002/a.php
I am using PHP with NGinx (FCGI). To compress the data I am using :
<?php
ob_start('ob_gzhandler');
phpinfo();
?>
When accessed via the browser it shows :
Vary: Accept-Encoding
But there is no Content-Encoding and the size of the downloaded data shown in Firebug is that of a non-compressed data.
When accessed from CLI using curl :
curl -H "Accept-Encoding: gzip" "http://104.194.26.13:2002/a.php"
There are some gbiresh characters suggesting it did encode. If you save the output with the above command the size is 17.5 KB instead of the 75 KB when accessed via the browser.
Here is the full headers received from my a.php file :
Connection: keep-alive
Content-Length: 75550
Content-Type: text/html
Date: Fri, 15 Jan 2016 05:37:43 GMT
Server: nginx
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.27
What could be possibly wrong ?
Which browser are you using, because Chrome 47.0.2526.106 m shows this:
Now, as stated in the comments, why don't you try and compress it directly from Nginx? By leveraging gzip compression within the nginx config:
# enable gzip compression
gzip on;
gzip_min_length 1100;
gzip_buffers 4 32k;
gzip_types text/plain application/x-javascript text/xml text/css;
gzip_vary on;
# end gzip configuration
Source
Here are my request headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:104.194.26.13:2002
Referer:http://stackoverflow.com/questions/34805168/nginx-and-php-gzip-compression-not-working-in-browser-but-works-in-curl/34805312?noredirect=1
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

How can i log response code from server

i need to log the response header/code from the server?
How can i do this? With NginX or with PHP/Curl?
An example:
(This i the request from the client)
----------------Request-------------------------
GET /download.php?request=abc123xyz&link=http%3A%2F%2Fyoutube.com%2Fwatch?v=pRPOztxXWlQ HTTP/1.1
Host: api.example.com
Accept-Encoding: gzip,deflate
Cache-Control: no-cache
Pragma: no-cache
Accept-Language: de, en-gb;q=0.9, en;q=0.8
Accept: application/json
User-Agent: JDownloader
Answer from my Server (Response Code/Header)
----------------Response Information------------
Connection-Time: keep-Alive
----------------Response------------------------
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 28 Nov 2014 12:03:32 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Strict-Transport-Security: max-age=63072000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
------------------------------------------------
I need this, because i have sometimes problems with the download of different files. My service downloads videos from some streamhoster like youtube. The output of the response code helps me to know if this a problem with my server or with the external downloader (JDownloader, Load!, ...)
Add header content in your access log with $http_<my_header> variables where <my_header> is the desired header name in lower can with dashes replaced by underscores. For instance X-Frame-Options could be logged with $http_x_frame_options added to access logformat.

WordPress doesn't respect nginx headers

I host some websites on my VPS, some "static" and some dynamic (WordPress). The static websites (static PHP pages) "respect" the headers I set in nginx conf, http section. Example:
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
add_header X-Cache $upstream_cache_status;
Header:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 16 Sep 2014 17:09:04 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Cache: HIT
Strict-Transport-Security: max-age=31536000; includeSubdomains;
WordPress websites instead don't have these headers I set:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 16 Sep 2014 17:08:25 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Pingback: http://website.com/xmlrpc.php
Link: <http://wp.me/P4zIfv-2>; rel=shortlink
X-UA-Compatible: IE=Edge,chrome=1
The two websites have the same vhost config! Of course liste, server_name, index ecc.. and then the locations:
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_cache website.com;
fastcgi_cache_valid 200 20m;
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include /etc/nginx/fastcgi.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
Why does this happen with WP?
See: nginx add_header not working
"Second issue was that the location / {} block I had in place was actually sending nginx to the other location ~* (.php)$ block (because it would repath all requests through index.php, and that actually makes nginx process this php block). So, my add_header directives inside the first location directive were useless, and it started working after I put all the directives I needed inside the php location directive."
See also: https://gist.github.com/adityamenon/6753574
So put them INSIDE your location block

Categories