I want to disable the trace and track methods via htaccess.
With following snippet in my htaccess:
RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
RewriteRule .* - [L,R=405]
I get the following answers
url -v -X TRACK obscuredurl* Adding handle: conn: 0x7f8c43004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f8c43004400) send_pipe: 1, recv_pipe: 0
* About to connect() to obscuredurl port 80 (#0)
* Trying xx.xx.xxx.xx...
* Connected to obscuredurl (xx.xx.xxx.xx) port 80 (#0)
> TRACK / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: obscuredurl
> Accept: */*
>
< HTTP/1.1 405 Method Not Allowed
< Date: Tue, 14 Jan 2014 09:53:45 GMT
* Server Apache is not blacklisted
< Server: Apache
< Allow: TRACE
< Content-Length: 296
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACK is not allowed for the URL /.</p>
<hr>
<address>Apache Server at obscuredurl Port 80</address>
</body></html>
* Closing connection 0
And
curl -v -X TRACE obscuredurl
* Adding handle: conn: 0x7ff339004400
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7ff339004400) send_pipe: 1, recv_pipe: 0
* About to connect() to obscuredurl port 80 (#0)
* Trying xx.xx.xxx.xx...
* Connected to obscuredurl (xx.xx.xxx.xx) port 80 (#0)
> TRACE / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: obscuredurl
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 14 Jan 2014 09:55:15 GMT
* Server Apache is not blacklisted
< Server: Apache
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: message/http
<
TRACE / HTTP/1.1
User-Agent: curl/7.30.0
Host: obscuredurl
Accept: */*
* Closing connection 0
So it seems to work with TRACK but not with trace. Two separated conditions work either.
How can I debug it?
Thanks
Difference is in Apache handling of TRACE and TRACK request methods. As you noticed TRACK request is duly handled by mod_rewrite rule in Apache but TRACE is handled by Apache at much higher level even before reading your .htacess You can verify that by putting some garbage text in .htaccess and then invoking TRACE request to get a proper response instead of expected 500 (Internal Server Error).
You may need to request your server admin to add this in Apache server config:
TraceEnable Off
to switch off TRACE.
Related
vuejs is running inside a docker container served by:
CMD [ "http-server", "dist" ]
when using axios inside Vue.js mounted() to do a GET request against a flask api it shows "blocked" in the network tab, accessing other REST-API's works fine.
testing with curl (localhost:6000 being the flask server):
- curl is running from my real host and conneting to the container
curl -H "Origin: http://localhost:5000"
-H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: X-Requested With"
-X OPTIONS --verbose http://localhost:6000/todo/api/v1.0/wheel/40
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 6000 (#0)
> OPTIONS /todo/api/v1.0/wheel/40 HTTP/1.1
> Host: localhost:6000
> User-Agent: curl/7.58.0
> Accept: */*
> Origin: http://localhost:5000
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: X-Requested-With
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: text/html; charset=utf-8
< Allow: OPTIONS, GET, HEAD
< Access-Control-Allow-Origin: http://localhost:5000
< Access-Control-Allow-Headers: X-Requested-With
< Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
< Vary: Origin
< Content-Length: 0
< Server: Werkzeug/1.0.0 Python/3.8.2
< Date: Sun, 15 Mar 2020 15:43:44 GMT
<
* Closing connection 0
from what ive read so far, for example here: 1, for a unauthorized GET request the headers look ok.
This one gets the real data:
curl -H "Origin: http://l:5000" -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: X-Requested-With" -v http://localhost:6000/todo/api/v1.0/wheel/40
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 6000 (#0)
> GET /todo/api/v1.0/wheel/40 HTTP/1.1
> Host: localhost:6000
> User-Agent: curl/7.58.0
> Accept: */*
> Origin: http://l:5000
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: X-Requested-With
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: application/json
< Content-Length: 39
< Access-Control-Allow-Origin: http://l:5000
< Vary: Origin
< Server: Werkzeug/1.0.0 Python/3.8.2
< Date: Sun, 15 Mar 2020 15:56:43 GMT
<
{"result":{"model 1":0,"model 2":150}}
* Closing connection 0
Manipulating -H "Origin..." to this:
-H "Origin: http://l:5000"
also shows a normal reply. Isn't that a good test?
As it turns out mozilla allows certain ports for certain protocols as shown here:
https://developer.mozilla.org/en-US/docs/Mozilla/Mozilla_Port_Blocking
6000 is the "x11" port and on that list - As port for x11 and not to be used for xhr. So every port not on that list should do the trick.
reason:
Cert issued a Vulnerability Note VU#476267 for a "Cross-Protocol" scripting attack, known as the HTML Form Protocol Attack
In your app's __init__.py file add these lines and you'll be good to go.
$ pip install flask-cors
from flask_cors import CORS
app = Flask(__name__)
CORS(app)
Read more about CORS here-- MDN CORS
I've a simple API Gateway, that sends the data to an HTTP endpoint (Express/Node).
For testing, I'm using curl, which is great. Sending the curl request without CORS works like a charm, however if I try to mimic CORS in curl, I get a HTTP 500 and have no idea why. These are both requests:
curl -v -H "X-Api-Key: myapikey" -H "Origin: example.com" "https://apigatewayid.execute-api.us-west-2.amazonaws.com/dev/path/prettyParam?anotherParam=1"
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to apigatewayid.execute-api.us-west-2.amazonaws.com (x.x.x.x) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.execute-api.us-west-2.amazonaws.com
* Server certificate: Symantec Class 3 Secure Server CA - G4
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> GET /dev/path/prettyParam?anotherParam=1 HTTP/1.1
> Host: apigatewayid.execute-api.us-west-2.amazonaws.com
> User-Agent: curl/7.51.0
> Accept: */*
> X-Api-Key: myapikey
> Origin: example.com
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 64
< Connection: keep-alive
< Date: Fri, 21 Jul 2017 00:28:50 GMT
< x-amzn-RequestId: numbers-6dab-11e7-b411-b7f8fd6c0cc3
< Access-Control-Allow-Origin: *
< X-Amzn-Trace-Id: Root=1-5morenumbersletters3e8be5c86a2c72781a0b356
< X-Cache: Miss from cloudfront
< Via: 1.1 numbersletters7a8621aabe6b30d2f5a48.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: numberslettersUk3Bs9dL4KJR4QccPmILA4tJUjO0X_h7cQc9DxA==
<
* Curl_http_done: called premature == 0
* Connection #0 to host apigatewayid.execute-api.us-west-2.amazonaws.com left intact
{"resultDataFromServer":"dataReceived!"}
curl -H "Origin: example.com" -H "X-Api-Key: myapikey" -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: X-Requested-With" -X OPTIONS --verbose "https://apigatewayid.execute-api.us-west-2.amazonaws.com/dev/path/prettyParam?anotherParam=1"
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to apigatewayid.execute-api.us-west-2.amazonaws.com (x.x.x.x) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.execute-api.us-west-2.amazonaws.com
* Server certificate: Symantec Class 3 Secure Server CA - G4
* Server certificate: VeriSign Class 3 Public Primary Certification Authority - G5
> OPTIONS /dev/path/prettyParam?anotherParam=1 HTTP/1.1
> Host: apigatewayid.execute-api.us-west-2.amazonaws.com
> User-Agent: curl/7.51.0
> Accept: */*
> X-Api-Key: myapikey
> Access-Control-Request-Method: GET
> Access-Control-Request-Headers: X-Requested-With
>
< HTTP/1.1 500 Internal Server Error
< Content-Type: application/json
< Content-Length: 36
< Connection: keep-alive
< Date: Fri, 21 Jul 2017 00:29:07 GMT
< x-amzn-RequestId: numbers-6dab-11e7-b411-b7f8fd6c0cc3
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token
< Access-Control-Allow-Methods: GET,OPTIONS
< X-Cache: Miss from cloudfront
< Via: 1.1 numbersletters7a8621aabe6b30d2f5a48.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: numberslettersUk3Bs9dL4KJR4QccPmILA4tJUjO0X_h7cQc9DxA==
<
* Curl_http_done: called premature == 0
* Connection #0 to host apigatewayid.execute-api.us-west-2.amazonaws.com left intact
{"message": "Internal server error"}
I really don't understand what I'm doing wrong. I enabled CORS in the API Gateway, and in Express CORS is enabled also, so not sure what is going on.
#Raul, did you test your API method via API Gateway? Try deploying your API again and test it from the APIGateway itself by providing the URL param. If you get the same {"message": "Internal server error"} there is a problem with the code. Sometimes it might look like a CORS issue, but actually it could be a lambda logic error.
I am newbie to the "WSO2 ESB" platform. I am trying to run the WSO2 ESB Rest API example from https://docs.wso2.com/display/ESB481/Sample+800%3A+Introduction+to+REST+API, so I followed all steps
1) on one terminal, I execute
C:\wso2esb-4.8.1\samples\axis2Server>axis2server.bat
2) On another terminal
C:\wso2esb-4.8.1\bin>wso2esb-samples.bat -sn 800
and when I run the following Rest URL it gives me error. Please help me to know why last CURL command not giving the required output?
C:\>curl -v http://127.0.0.1:8280/stockquote/view/IBM
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8280 (#0)
> GET /stockquote/view/IBM HTTP/1.1
> User-Agent: curl/7.40.0
> Host: 127.0.0.1:8280
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/xml; charset=UTF-8
< Date: Sat, 25 Jul 2015 10:25:19 GMT
< Server: WSO2-PassThrough-HTTP
< Transfer-Encoding: chunked
<
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelop
e/"><soapenv:Body><ns:getQuoteResponse xmlns:ns="http://services.samples"><ns:return xmlns:ax21="http://servic
es.samples/xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax21:GetQuoteResponse"><ax21:c
hange>-2.6661865959844184</ax21:change><ax21:earnings>-9.163558543387456</ax21:earnings><ax21:high>193.7355458
031858</ax21:high><ax21:last>185.33888561996295</ax21:last><ax21:lastTradeTimestamp>Sat Jul 25 15:55:19 IST 20
15</ax21:lastTradeTimestamp><ax21:low>-181.04727326807318</ax21:low><ax21:marketCap>5.0117544767788365E7</ax21
:marketCap><ax21:name>IBM Company</ax21:name><ax21:open>-183.267380995112</ax21:open><ax21:peRatio>-19.7725282
3298653</ax21:peRatio><ax21:percentageChange>-1.3311819845208677</ax21:percentageChange><ax21:prevClose>200.28
716035727143</ax21:prevClose><ax21:symbol>IBM</ax21:symbol><ax21:volume>9220</ax21:volume></ns:return></ns:get
QuoteResponse></soapenv:Body></soapenv:Envelope>* Connection #0 to host 127.0.0.1 left intact
C:\>
C:\>curl -v http://127.0.0.1:8280/stockquote/view/MSFT
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8280 (#0)
> GET /stockquote/view/MSFT HTTP/1.1
> User-Agent: curl/7.40.0
> Host: 127.0.0.1:8280
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/xml; charset=UTF-8
< Date: Sat, 25 Jul 2015 10:27:52 GMT
< Server: WSO2-PassThrough-HTTP
< Transfer-Encoding: chunked
<
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelop
e/"><soapenv:Body><ns:getQuoteResponse xmlns:ns="http://services.samples"><ns:return xmlns:ax21="http://servic
es.samples/xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ax21:GetQuoteResponse"><ax21:c
hange>-2.349071151386308</ax21:change><ax21:earnings>13.743507564027315</ax21:earnings><ax21:high>-71.04465262
35375</ax21:high><ax21:last>72.46275193434585</ax21:last><ax21:lastTradeTimestamp>Sat Jul 25 15:57:52 IST 2015
</ax21:lastTradeTimestamp><ax21:low>-72.22389056575905</ax21:low><ax21:marketCap>-6410999.83409811</ax21:marke
tCap><ax21:name>MSFT Company</ax21:name><ax21:open>-71.12518655378832</ax21:open><ax21:peRatio>23.786563750758
063</ax21:peRatio><ax21:percentageChange>-2.922305475406254</ax21:percentageChange><ax21:prevClose>80.38417513
691802</ax21:prevClose><ax21:symbol>MSFT</ax21:symbol><ax21:volume>8234</ax21:volume></ns:return></ns:getQuote
Response></soapenv:Body></soapenv:Envelope>* Connection #0 to host 127.0.0.1 left intact
C:\>curl -v -d #placeorder.xml -H "Content-type: application/xml" http://127.0.0.1:8280/stockquote/order/
Warning: Couldn't read data from file "placeorder.xml", this makes an empty
Warning: POST.
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8280 (#0)
> POST /stockquote/order/ HTTP/1.1
> User-Agent: curl/7.40.0
> Host: 127.0.0.1:8280
> Accept: */*
> Content-type: application/xml
> Content-Length: 0
>
< HTTP/1.1 202 Accepted
< Date: Sat, 25 Jul 2015 10:28:25 GMT
< Server: WSO2-PassThrough-HTTP
< Transfer-Encoding: chunked
<
* Connection #0 to host 127.0.0.1 left intact**
server Logs:
15/07/25 15:53:57 INFO util.SampleAxis2ServerManager: [SimpleAxisServer] Started
Sat Jul 25 15:55:19 IST 2015 samples.services.SimpleStockQuoteService :: Generating quote for : IBM
Sat Jul 25 15:57:52 IST 2015 samples.services.SimpleStockQuoteService :: Generating quote for : MSFT
15/07/25 15:58:25 ERROR receivers.RPCInOnlyMessageReceiver: Exception occurred while trying to invoke service
method placeOrder
java.lang.IllegalArgumentException: wrong number of arguments
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:178)
at org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver.invokeBusinessLogic(RPCInOnlyMessageReceive
r.java:66)
at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:1
72)
at org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:459)
at org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:279)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
15/07/25 15:58:25 ERROR receivers.AbstractMessageReceiver: org.apache.axis2.AxisFault: Exception occurred whil
e trying to invoke service method placeOrder
Edit-1: I created placeorder.xml file under /wso2esb-4.8.1 directory.
C:\WSO2-ESB\wso2esb-4.8.1>curl -v -d #placeorder.xml -H "Content-type: application/xml
" http://127.0.0.1:8280/stockquote/order/
Warning: Couldn't read data from file "placeorder.xml", this makes an empty
Warning: POST.
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8280 (#0)
> POST /stockquote/order/ HTTP/1.1
> User-Agent: curl/7.40.0
> Host: 127.0.0.1:8280
> Accept: */*
> Content-type: application/xml
> Content-Length: 0
>
< HTTP/1.1 202 Accepted
< Date: Sat, 25 Jul 2015 17:35:56 GMT
< Server: WSO2-PassThrough-HTTP
< Transfer-Encoding: chunked
<
* Connection #0 to host 127.0.0.1 left intact
From the link, it seems that "The ESB returns the 202 response back to the client" . Is this correct?
ERROR receivers.RPCInOnlyMessageReceiver: Exception occurred while
trying to invoke service method placeOrder
java.lang.IllegalArgumentException: wrong number of arguments
The above error happens when you are running the following command in your terminal.
curl -v -d #placeorder.xml -H "Content-type: application/xml"
http://127.0.0.1:8280/stockquote/order/
You have to run the above curl command from the directory where you have the placeorder.xml file. Do you have placeorder.xml file in the same directory? If not, you have to either run your command from the directory where you have placeorder.xml or you have to give the path to the placeorder.xml file when you run the above curl command.
Edit-1
You should create the placeorder.xml file with the following content and save it in your machine.
<placeOrder xmlns="http://services.samples">
<order>
<price>50</price>
<quantity>10</quantity>
<symbol>IBM</symbol>
</order>
</placeOrder>
Amazon recently rolled out a new feature on CloudFront that supports custom SSL certificates at no charge using SNI (Server Name Indication).
I got my distribution set up with a free Class 1 certificate from StartSSL and everything was working when I was noticing that the site would go down a short time after it's deployed. Running SSL Checker returns that my certificate is working properly:
But then I would hit this error page when trying to access the site via HTTPS (it would work for the first request then go down in subsequent attempts to connect).
Here's a verbose output when accessing with ssl (succeeds on index):
$ curl -I -v -ssl https://wikichen.is
* Adding handle: conn: 0x7f9f82804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9f82804000) send_pipe: 1, recv_pipe: 0
* About to connect() to wikichen.is port 443 (#0)
* Trying 54.230.141.222...
* Connected to wikichen.is (54.230.141.222) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_RC4_128_MD5
* Server certificate: www.wikichen.is (6w984WNu7vM5OrdU)
* Server certificate: StartCom Class 1 Primary Intermediate Server CA
* Server certificate: StartCom Certification Authority
> HEAD / HTTP/1.1
> User-Agent: curl/7.30.0
> Host: wikichen.is
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Content-Length: 1153
Content-Length: 1153
< Connection: keep-alive
Connection: keep-alive
< Date: Sun, 09 Mar 2014 16:09:54 GMT
Date: Sun, 09 Mar 2014 16:09:54 GMT
< Cache-Control: max-age=120
Cache-Control: max-age=120
< Content-Encoding: gzip
Content-Encoding: gzip
< Last-Modified: Wed, 05 Mar 2014 20:40:48 GMT
Last-Modified: Wed, 05 Mar 2014 20:40:48 GMT
< ETag: "34685bc45353d1030d3a515ddba78f3e"
ETag: "34685bc45353d1030d3a515ddba78f3e"
* Server AmazonS3 is not blacklisted
< Server: AmazonS3
Server: AmazonS3
< Age: 4244
Age: 4244
< X-Cache: Hit from cloudfront
X-Cache: Hit from cloudfront
< Via: 1.1 4f672256eaca5524999342dc8678cdd2.cloudfront.net (CloudFront)
Via: 1.1 4f672256eaca5524999342dc8678cdd2.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: h4TEULH44TCi7m2lL42A8lO-5-Gmx8iY2M2C1AOmRlK543zFN6jCtQ==
X-Amz-Cf-Id: h4TEULH44TCi7m2lL42A8lO-5-Gmx8iY2M2C1AOmRlK543zFN6jCtQ==
<
* Connection #0 to host wikichen.is left intact
Then fails on other pages:
$ curl -i -v https://wikichen.is/writing/index.html
* Adding handle: conn: 0x7fa153804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fa153804000) send_pipe: 1, recv_pipe: 0
* About to connect() to wikichen.is port 443 (#0)
* Trying 54.230.140.160...
* Connected to wikichen.is (54.230.140.160) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_RC4_128_MD5
* Server certificate: www.wikichen.is (6w984WNu7vM5OrdU)
* Server certificate: StartCom Class 1 Primary Intermediate Server CA
* Server certificate: StartCom Certification Authority
> GET /writing/index.html HTTP/1.1
> User-Agent: curl/7.30.0
> Host: wikichen.is
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
HTTP/1.1 502 Bad Gateway
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 472
Content-Length: 472
< Connection: keep-alive
Connection: keep-alive
* Server CloudFront is not blacklisted
< Server: CloudFront
Server: CloudFront
< Date: Sun, 09 Mar 2014 17:54:41 GMT
Date: Sun, 09 Mar 2014 17:54:41 GMT
< Age: 6
Age: 6
< X-Cache: Error from cloudfront
X-Cache: Error from cloudfront
< Via: 1.1 9096435f28f91f92bacdf76122de09ee.cloudfront.net (CloudFront)
Via: 1.1 9096435f28f91f92bacdf76122de09ee.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: iAUOQbP8O4A0pI9KGvVz0VgBT1TW-j0yVDa7vdSvIAuxnKOyQghtnw==
X-Amz-Cf-Id: iAUOQbP8O4A0pI9KGvVz0VgBT1TW-j0yVDa7vdSvIAuxnKOyQghtnw==
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
</BODY></HTML>
<BR clear="all">
<HR noshade size="1px">
<ADDRESS>
Generated by cloudfront (CloudFront)
</ADDRESS>
* Connection #0 to host wikichen.is left intact
</BODY></HTML>%
Would love some pointers as to where to start troubleshooting.
A kind rep by the name of Alastair#AWS from the AWS CloudFront forums solved this for me:
I have identified your CloudFront distribution and the S3 bucket
acting as the origin for this distribution.
I can re-create and explain the intermittent '502 Bad Gateway'
response you are receiving.
This response is returned by CloudFront when you attempt to access a
URL using the HTTPS protocol that is not currently cached by
CloudFront. The reason for this error is CloudFront is attempting to
contact your origin using the HTTPS protocol, and this is failing.
The reason for this failure is you have configured your origin as an
S3 bucket, but you are using the "Custom Origin" type and directing to
the S3 website URL for this bucket. If you attempt to hit your S3
website URL using HTTPS, you will note this does not work. S3 website
hosting only supports serving content using the HTTP protocol
(http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff).
Now, the intermittent page load behavior you are seeing is due to
CloudFront returning the pages it currently has in its cache. You
should be able to re-create this scenario as follows:
Hit a page on your site using HTTPS. You should get a '502 Bad Gateway' error back.
Hit the same page using HTTP. You should see the page.
Hit the page again using HTTPS. You should now get the expected result, as CF has served the content from its cache rather than
attempting to contact your origin.
To resolve this issue, please try the following:
Open the CloudFront Management Console and open your distribution.
Navigate to the Origins tab, select your origin and click "Edit"
Modify the "Origin Protocol Policy" to "HTTP Only".
Save the changes and wait about 15 minutes for the change to take effect.
Test
My expectation is this will force CloudFront to contact your origin
using HTTP only. I have tested this in my environment with an S3
Website hosted bucket and I can successfully load content via both
HTTP and HTTPS.
Here's the link to the original forum thread.
I had a similar issue to this and, as #Michael-sqlbot suggested, switched from custom origin to S3. That did not, by itself, resolve the issue.
In addition to switching the origin, Andrew from AWS support said that aliases work better than CNAMEs. I had been using CNAMEs. When I switched to aliases (one for IPv4 and one for IPv6) it worked. Here is the Route 53 documentation for CloudFront that shows how to setup aliases for CloudFront.
I was struggling a bit with having proper setup with own SSL Certificate, but this article was most helpful. Just pay attention to details:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/tutorial-redirecting-dns-queries.html
I have been looking at the usage reports from Amazons S3 service and noticed that there is a DataTransfer-out-bytes charge for GetObject operations (ok i understand this one) and also a DataTransfer-out-bytes charge for HeadBucket operations.
What is HeadBucket, when is this request made?
cheers
That's a HEAD request to a bucket:
HEAD /my-s3-bucket
Which will basically just tell you that a bucket exists (200 OK), or not (404 Not Found).
For Example:
# curl -v -X HEAD http://s3.amazonaws.com/fooXXXX
* About to connect() to s3.amazonaws.com port 80 (#0)
* Trying 72.21.211.144... connected
* Connected to s3.amazonaws.com (72.21.211.144) port 80 (#0)
> HEAD /fooXXXX HTTP/1.1
> User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
> Host: s3.amazonaws.com
> Accept: */*
>
< HTTP/1.1 404 Not Found
< x-amz-request-id: A21BF750F080A267
< x-amz-id-2: SPQ7yX6Ln0Zgp0YULT/64ag9077nNnN25jH8PMLGMm/SbXPZ+FF3qFuiOyBfiktP
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Date: Thu, 23 Apr 2009 13:39:50 GMT
< Server: AmazonS3
Vs.
# curl -v -X HEAD http://s3.amazonaws.com/s3hub
* About to connect() to s3.amazonaws.com port 80 (#0)
* Trying 72.21.207.135... connected
* Connected to s3.amazonaws.com (72.21.207.135) port 80 (#0)
> HEAD /s3hub HTTP/1.1
> User-Agent: curl/7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
> Host: s3.amazonaws.com
> Accept: */*
>
< HTTP/1.1 200 OK
< x-amz-id-2: E6OvrEMD35HpJjlBg0kB90H/uaQDX8qk0oXb+baOtDKIoMXmNwgIRSX2rDE5Urlb
< x-amz-request-id: DAAAA11524A4A557
< Date: Thu, 23 Apr 2009 13:43:01 GMT
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Server: AmazonS3
<