I try to do, but when i turn to bypass my domain A record, the protocol h2 is working.
All correct in browser and apache logs.
When i turn on the cloudflare on the domain, the browser is working fine(I know the CF is working on HTTP2 protocol with the clients).
But I saw these in the apache logs:
“GET / HTTP/1.1” 302 5067
"GET /en/ HTTP/1.1" 200 5068
"POST /en/ajax/user HTTP/1.1" 200 77
It's using http/1.1, but I don't know why.
I try to force http2 protocol, but no difference.
Any idea ?:slightly_smiling_face:
Thank you!
Cloudflare plans to use HTTP 1.1 to the origin for the foreseeable future.
https://support.cloudflare.com/hc/en-us/articles/214534978-Are-the-HTTP-2-or-SPDY-protocols-supported-between-Cloudflare-and-the-origin-server-
You can use HTTP/2 to origin as of June 14th, 2022:
1. Log into the [Cloudflare dashboard](https://dash.cloudflare.com/login) and select your account.
2. Choose the domain that will use HTTP/2 to Origin.
3. Click **Network**.
4. Under **HTTP/2 to Origin** set the toggle to On.
Refs are:
https://github.com/cloudflare/cloudflare-docs/blob/production/content/cache/how-to/enable-http2-to-origin.md
https://developers.cloudflare.com/cache/how-to/enable-http2-to-origin/
Related
just want to ask what does this apache logs mean? Although i know some of the meaning but did not really understand this logs line..
10.xx.x.xx - - [08/Dec/2021:08:06:12 +0000] "POST /endpoint HTTP/1.1" 200 511 "-" "PHP Curl/1.9 (+https://github.com/php-mod/curl)" "157.xxx.xx.xxx, 172.70.xxx.xxx"
My Server A (157.xxx.xx.xxx) is calling a http post method to another server B. So in this case not sure what kind of server config causing the client ip infront of the log showing that 10.xx.x.xx (look like private ip?) but my Server A ip is showing at behind as user agent and there is another ip show after my Server A iP (172.70.xxx.xxx)?
I suspect that the ip 10.xx.x.xx maybe is somekind of proxy or gateway ip? Maybe load balancer, nginx, cloudflare or etc?
Can anyone help to explain this? Thanks guys..
On apache access log, I find out that https return bigger size than http
210.10.0.156 - - [29/Apr/2019:12:22:46 +0800] "GET /robots.txt HTTP/1.1" 200 5837 "-" "curl/7.52.1"
If you can see it is 5837 bytes where is for http less than 1000 bytes
my robots.txt content is only
User-agent: *
Disallow: /
Is this a normal things?
When i tried to do same thing on other server with cpanel installed, the size is much more lower, im not sure what configuration i missed, any advise?
Yes, this is perfectly normal.
Your website may not be configured for HTTP, which will redirect people to HTTPS with a 301 or 302 rule, meaning all they see when they access your site through HTTP is a redirect page, which is usually smaller than the regular webpage which they were expecting.
You can go to your website with http:// or https:// at the start of the URL and see if it looks any different.
I have disabled SSL in all pages at Prestashop and now there is this error (i do not enter https and it puts https):
I tried deleting htaccess and regenerating it, but it didn't work.
This is the Prestashop configuration:
Which is the solution?
EDIT: My configuration of SSL at Prestashop configuration tab
I'm not familiar with Prestashop, however the issue is that at the time being the site enforces the HTTPS. In fact, the non-HTTPS version redirects to the HTTPS, there may be other redirects (that are not enabled now as I can access the redirect target) that may have caused the loop.
➜ ~ curl -I http://runvaspain.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 24 Jan 2016 10:44:09 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: https://runvaspain.com/
X-Powered-By: PleskLin
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15768000;includeSubDomains
Moreover, it looks like the site is setting the HSTS header
Strict-Transport-Security: max-age=15768000;includeSubDomains
This header is ignored when served via HTTP, however I suppose this was also served via HTTPS, therefore your browser have probably saved the configuration and it's enforcing the HTTPS locally (given that's what the HSTS is about).
You'll have to manually remove the strict transport configuration for the domain in your browser. However, please note that any user that previously accessed your site will have such setting, therefore they will be forced to use HTTPS for the main site and all subdomains for 6 months (as this is the policy you previous set).
Also note that, since you previously sent that header, HTTPS will be enabled for the entire site (and also subdomains), it's not possible to enable it on a single page (at least for the users who visited it before). The best thing to do is to turn HTTPS on again for the entire site.
To solve the first issue (the redirect to HTTPS) you should contact the Prestashop service. However, please note it will be almost irrelevant if the HSTS header was previously sent.
The http version of the website ( http://runvaspain.com ) send a 301 redirect to the https version.
The https version of the website ( https://runvaspain.com ) use the HSTS header with a max-age of 6 month
That's mean that anyone who visited the website is forced to visit the HTTPS version
It's a security feature added by HSTS.
You have two solutions:
Reactivate the https version (It's my advice, as https add a significant security to your visitors)
Redirect the https to http AND modify the HSTS header (probably in your apache configuration) to send a max-age of 0. You MUST send it for at least 6 month, you can't just remove it! Sending a max-age on 0 indicate to visitors who already visited the website to forget the HSTS settings. If you just remove it, those visitors will not be able to visits the webpage for the next six months !
in prestashop after configure with ssl, admin dashboard works. but public sites doesn't work anymore. because you have to enable SSL for front pages, using admin dashboard like bellow.
Enable SSL - yes
Enable SSL on all pages - yes
change your shop parameters like this
refer the image
I think Chrome just cached the URL. Happens to me all the time during development.
Try
List item
Click Menu (three dots or whatever icon is it now in Chrome in the upper right corner)
Hover over More tools then Developer tools
Click Network tab
Click Disable cache checkbox
Why can't I see why Apache returns 403?!
If I look in the access log the only information I get is
193.162.142.166 - - [29/Jan/2014:18:34:26 +0100] "POST /api_test/callback.php HTTP/1.1" 403 2293
How can I get more information about why the request is forbidden/rejected?
The call is made from a payment gateway...
If the callback URL is a http request there are no problems and returns 200 OK
If the callback URL is a https my server returns 403.. I need to know why?
The server has SSL and openSSL installed and it works!
Have tried to do the https request from http://web-sniffer.net/ and then there are no problems..
I don't get it.. There must be something in the request headers from the payment gateway which results in 403
update
error log
[Wed Jan 29 20:45:55 2014] [error] No hostname was provided via SNI for a name based virtual host
solution
Ok it looks like the client doesn't support SNI
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Use the LogLevel directive to adjust how verbose the error logs are and increase until you can see what you want.
httpd 2.4 has better messages in a lot of respect and expensive list of LogLevel settings than 2.2. So if you're using 2.2 it may be a bit harder to figure this out.
I have set up an Apache server to use mod_auth_kerb. It authenticates users via Kerberos and the Negotiate protocol, allowing them entry to the site if they hold a valid Kerberos ticket. It works in that it properly authenticates users. There is a problem however: HTTP 401 response codes clutter the Apache log file. They're from the same IP address each time, so I know that a client attempts to access the page, receives a 401, then tries again and gets an HTTP 200 OK back on the second try. It looks like the user is unidentified in the first attempt, but identified properly in the second attempt.
1.2.3.4 - - [07/Jan/2014:12:29:16 -0500] "GET /my_url/ HTTP/1.1" 401 1005
1.2.3.4 - user#REALM.EXAMPLE.COM [07/Jan/2014:12:29:16 -0500] "GET /my_url/ HTTP/1.1" 200 1724
How can I find out what is causing these 401 unauthorized responses? I can't record it over Wireshark because the connection is encrypted with HTTPS and TLS. Chrome's Developer Tools is only showing HTTP 200 OK responses, but I know that 401s are being generated from the Apache server logs. Any thoughts?
This is how HTTP Authentication works.
There is nothing you can do about it.