I have a configuration where I'm rewriting request to a %{DOCUMENT_ROOT}/break/break_on.html when %{DOCUMENT_ROOT}/break/break_on.enable file exists.
Look at CONDITION NR1
DocumentRoot /opt/IBM/HTTPServer/htdocs
RewriteEngine On
# CONDITION NR1
RewriteCond %{DOCUMENT_ROOT}/break/break_on.html -f
RewriteCond %{DOCUMENT_ROOT}/break/break_on.enable -f
RewriteCond %{SCRIPT_FILENAME} !break/break_on.html
RewriteRule (.*) /break/break_on.html [PT,L]
This was always working with traditional WebSphere. Now since I have WebSphere Liberty with dynamicRouting enabled, the dynamicRouting is sending a request to WebSphere Liberty Servers instead of rediricting it to local %{DOCUMENT_ROOT}/break/break_on.html
Status line for URI [/break/break_on.html] client port [60960] transport [libertyController:9080]: HTTP/1.1 404 Not Found
[11/Feb/2023:16:49:47.46640] 00013a65 30115700 - ODR:DEBUG: Reading response headers for URI [/break/break_on.html] client port [60960] transport [libertyController:9080]:
Look at http_plugin.log:
[11/Feb/2023:16:49:47.46208] 00013a65 30094700 - ODR:INFO: http.summary: [0x7f8604008920] RESPONSE_SENT Initial 20.45.100.115 GET HTTP/1.1 http://break/break_on.html?v=2 libertyNode:9080 0 404 5ms 9ms
[11/Feb/2023:16:49:47.46209] 00013a65 30094700 - ODR:DEBUG: odrHttpContextSetStateInternal: exit
[11/Feb/2023:16:49:47.46210] 00013a65 30094700 - ODR:DEBUG: odrHttpContextRelease: deleting proxy=0x7f8604008bb0 delegate=0x7f8604008920
[11/Feb/2023:16:49:47.46211] 00013a65 30094700 - ODR:DEBUG: odrHttpContextRelease: enter - ctx=0x7f8604008920
[11/Feb/2023:16:49:47.46212] 00013a65 30094700 - ODR:DEBUG: odrHttpContextClean: enter - ctx=0x7f8604008920
[11/Feb/2023:16:49:47.46213] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.tsLockObtain: ts=0x7f8624000c40 obtained lock=0x7f8624000cf0 (heldBy=NOBODY) for tsTargetInfoDecrementRefCnt
[11/Feb/2023:16:49:47.46214] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.tsTargetinfoDecrementRefCnt: sapp 0x7f862415ef50, tep 2, server 2, node 2, cluster 5, cell 3
[11/Feb/2023:16:49:47.46215] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.endPointDelete: Releasing reference to endpoint /cell/defaultCollective/node/libertyNode,%2Fapp%2FIBM%2FLiberty%2Fusr/server/srv_libertyApp_1/transport/Http; refcnt=2
[11/Feb/2023:16:49:47.46216] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.serverDelete: release /cell/defaultCollective/node/libertyNode,%2Fapp%2FIBM%2FLiberty%2Fusr/server/srv_libertyApp_1 (refcnt=1)
[11/Feb/2023:16:49:47.46218] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.nodeDelete: node 0x7f86241014a0: release /cell/defaultCollective/node/libertyNode,%2Fapp%2FIBM%2FLiberty%2Fusr (refcnt=1)
[11/Feb/2023:16:49:47.46219] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.cellDelete: cell 0x7f862406bb70: release /cell/defaultCollective (refcnt=2)
[11/Feb/2023:16:49:47.46220] 00013a65 30094700 - ODR:DEBUG: odrTargetSelector.tsLockRelease: ts=0x7f8624000c40 released lock=0x7f8624000cf0 (heldBy=tsTargetInfoDecrementRefCnt)
[11/Feb/2023:16:49:47.46221] 00013a65 30094700 - ODR:DEBUG: odrHttpContextClean: exit
[11/Feb/2023:16:49:47.46222] 00013a65 30094700 - ODR:DEBUG: odrHttpContextSetStateInternal: enter - ctx=0x7f8604008920, state=CACHED, url=
[11/Feb/2023:16:49:47.46223] 00013a65 30094700 - ODR:DEBUG: odrHttpContextSetStateInternal: exit
[11/Feb/2023:16:49:47.46223] 00013a65 30094700 - ODR:DEBUG: odrRoutingInfoRelease: enter - ri=0x7f86240008e0
[11/Feb/2023:16:49:47.46224] 00013a65 30094700 - ODR:DEBUG: odrRoutingInfoRelease: refCount=2, ri=0x7f86240008e0
[11/Feb/2023:16:49:47.46225] 00013a65 30094700 - ODR:DEBUG: odrRoutingInfoRelease: exit
[11/Feb/2023:16:49:47.46226] 00013a65 30094700 - ODR:DEBUG: odrHttpContextRelease: exit
[11/Feb/2023:16:49:47.46637] 00013a65 30115700 - ODR:DEBUG: Status line for URI [/break/break_on.html] client port [60960] transport [libertyController:9080]: HTTP/1.1 404 Not Found
[11/Feb/2023:16:49:47.46640] 00013a65 30115700 - ODR:DEBUG: Reading response headers for URI [/break/break_on.html] client port [60960] transport [libertyController:9080]:
[11/Feb/2023:16:49:47.46641] 00013a65 30115700 - ODR:DEBUG: X-Powered-By: Servlet/3.1
[11/Feb/2023:16:49:47.46642] 00013a65 30115700 - ODR:DEBUG: Content-Type: text/html
[11/Feb/2023:16:49:47.46643] 00013a65 30115700 - ODR:DEBUG: $WSEP:
[11/Feb/2023:16:49:47.46644] 00013a65 30115700 - ODR:DEBUG: Date: Sat, 11 Feb 2023 15:49:47 GMT
[11/Feb/2023:16:49:47.46645] 00013a65 30115700 - ODR:DEBUG: Last-Modified: Wed, 04 Jan 2023 14:12:12 GMT
[11/Feb/2023:16:49:47.46646] 00013a65 30115700 - ODR:DEBUG: Content-Length: 2109
[11/Feb/2023:16:49:47.46647] 00013a65 30115700 - ODR:DEBUG: Content-Language: en-US
[11/Feb/2023:16:49:47.46648] 00013a65 30115700 - ODR:DEBUG: Connection: Close
[11/Feb/2023:16:49:47.46649] 00013a65 30115700 - ODR:DEBUG: odrHttpContextSetStateInternal: enter - ctx=0x7f86140028f0, state=RESPONSE_ARRIVED, url=
[11/Feb/2023:16:49:47.46650] 00013a65 30115700 - ODR:DEBUG: odrHttpContextPerformResponseProcessing: wsptHdr=null, partitionVerHdr=null
[11/Feb/2023:16:49:47.46651] 00013a65 30115700 - ODR:DEBUG: getResponseSessionCookie: Checking if session cookie JSESSIONID is present in the response
[11/Feb/2023:16:49:47.46652] 00013a65 30115700 - ODR:DEBUG: getResponseSessionCookie: No session cookie found in the response
[11/Feb/2023:16:49:47.46653] 00013a65 30115700 - ODR:DEBUG: getCookieValue: cookieHeaderValue=null
[11/Feb/2023:16:49:47.46653] 00013a65 30115700 - ODR:DEBUG: getRequestSessionCookieValue: Checking if session cookie JSESSIONID is present in the request
[11/Feb/2023:16:49:47.46655] 00013a65 30115700 - ODR:DEBUG: getRequestSessionCookieValue: No session cookie found in the request
[11/Feb/2023:16:49:47.46656] 00013a65 30115700 - ODR:DEBUG: odrTargetSelector.tsLockObtain: ts=0x7f8624000c40 obtained lock=0x7f8624000cf0 (heldBy=NOBODY) for tsServerApplicationDecrementOutstandingRequestCount
[11/Feb/2023:16:49:47.46657] 00013a65 30115700 - ODR:DEBUG: hmCheckHealthPolicies: Server='/cell/defaultCollective/node/libertyController,%2Fapp%2FIBM%2FLiberty%2Fusr/server/srv_libertyApp_2' avgRT=10 timeoutPct=0
[11/Feb/2023:16:49:47.46658] 00013a65 30115700 - ODR:DEBUG: odrTargetSelector.tsLockRelease: ts=0x7f8624000c40 released lock=0x7f8624000cf0 (heldBy=tsServerApplicationDecrementOutstandingRequestCount)
[11/Feb/2023:16:49:47.46659] 00013a65 30115700 - ODR:DEBUG: odrHttpContextSetStateInternal: exit
[11/Feb/2023:16:49:47.46665] 00013a65 30115700 - ODR:DEBUG: odrHttpContextSetStateInternal: enter - ctx=0x7f86140028f0, state=RESPONSE_SENT, url=
So it's obvious that I get 404, this resource doesn't exist on libertyNode, it exists where I have IBM HTTP Server installed.
How can I make sure, that all request are going to %{DOCUMENT_ROOT}/break/break_on.html when %{DOCUMENT_ROOT}/break/break_on.enable file exist on localhost instead of going to WebSphere Liberty Controller?
Thanks!
Since the URL shares a context root with a deployed application, you'll have to get the websphere plugin to decline handling it and let it defer to the default static file handler (very low priority):
The skipwas environment variable is the flexible way to handle this:
RewriteRule (.*) /break/break_on.html [PT,L,E=skipwas:1]
I don't think there's a tWAS vs Liberty difference here, or even dynamic routing. I think you were mapping your applications differently (or inadvertently have an application mapped to /)
Related
First time poster with a bizarre issue I am having. I usually install software through conda, but from one moment to the other I stopped being able to use conda install because of a 403 I get from conda trying to access some configuration files. When trying to download those files with wget --spider --debug https://conda.anaconda.org/anaconda/noarch/current_repodata.json, I get the same 403 error.
DEBUG output created by Wget 1.19.4 on linux-gnu.
Reading HSTS entries from /home/jsequeira/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'current_repodata.json' (UTF-8) -> 'current_repodata.json' (UTF-8)
Spider mode enabled. Check if remote file exists.
--2020-07-30 11:25:59-- https://conda.anaconda.org/anaconda/noarch/current_repodata.json
Resolving conda.anaconda.org (conda.anaconda.org)... 104.17.92.24, 104.17.93.24, 2606:4700::6811:5d18, ...
Caching conda.anaconda.org => 104.17.92.24 104.17.93.24 2606:4700::6811:5d18 2606:4700::6811:5c18
Connecting to conda.anaconda.org (conda.anaconda.org)|104.17.92.24|:443... connected.
Created socket 5.
Releasing 0x000056545deb1850 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 5 to SSL handle 0x000056545deb2700
certificate:
subject: CN=anaconda.org,O=Cloudflare\\, Inc.,L=San Francisco,ST=CA,C=US
issuer: CN=Cloudflare Inc ECC CA-3,O=Cloudflare\\, Inc.,C=US
X509 certificate successfully verified and matches host conda.anaconda.org
---request begin---
HEAD /anaconda/noarch/current_repodata.json HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: conda.anaconda.org
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 403 Forbidden
Date: Thu, 30 Jul 2020 11:25:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
CF-Chl-Bypass: 1
Set-Cookie: __cfduid=d3cd3a67d3926551371d8ffe5a840b04f1596108359; expires=Sat, 29-Aug-20 11:25:59 GMT; path=/; domain=.anaconda.org; HttpOnly; SameSite=Lax
Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 01 Jan 1970 00:00:01 GMT
X-Frame-Options: SAMEORIGIN
cf-request-id: 044111dd9600005d4732b73200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Vary: Accept-Encoding
Server: cloudflare
CF-RAY: 5baeb8dc2ba65d47-LIS
---response end---
403 Forbidden
cdm: 1
Stored cookie anaconda.org -1 (ANY) / <permanent> <insecure> [expiry 2020-08-29 11:25:59] __cfduid d3cd3a67d3926551371d8ffe5a840b04f1596108359
URI content encoding = ‘UTF-8’
Closed 5/SSL 0x000056545deb2700
Remote file does not exist -- broken link!!!
These files are accessible through the browser, and were always accessible with wget and conda until yesterday, when I was installing some tools not related to these network accesses. How can wget fail to download them?
So this was fixed by reinstalling apt-get. Some configuration file there must have been messed up.
When i am using curl command to check the kibana status , it says:
curl -I http://localhost:5601/status
HTTP/1.1 503 Service Unavailable
retry-after: 30
content-type: text/html; charset=utf-8
cache-control: no-cache
content-length: 30
Date: Sat, 04 May 2019 12:50:18 GMT
Connection: keep-alive
Kibana.YML file
cat /etc/kibana/kibana.yml
elasticsearch.url: "http://10.0.1.41:9200"
server.port: 5601
server.host: "localhost"
server.ssl.enabled: false
logging.dest: /var/log/kibana/kibana.log
Can someone help me here to solve the 503 error?
Tried to get change the Kibana.yml but noluck
Issue was with Amazon Linux AMI, which has been resolved now.
What is the first HTTP request I should send for a proper websocket handshake?
I am sending GET / HTTP/1.1 with some other standard websocket headers but I get a 400 Bad Request. See below
$ telnet localhost 8889
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
GET / HTTP/1.1
Host: ws-feed.exchange.coinbase.com
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.test.com
HTTP/1.1 400 Bad Request
Server: cloudflare-nginx
Date: Thu, 10 Sep 2015 19:25:54 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d3fe870c84fc991b0f2f6fc2c936820471441913154; expires=Fri, 09-Sep-16 19:25:54 GMT; path=/; domain=.coinbase.com; HttpOnly
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
CF-RAY: 223d857c6bae01ee-EWR
0
Sec-WebSocket-Version header and Sec-WebSocket-Key header are missing.
I've been working on a development box deploying an Nginx, Magento, HHVM model. The site loads nicely and I don't get any real clear errors that I can see. However, a good number of my images are not loading properly. All I get are the image dimensions. The version of HHVM I'm using is:
HipHop VM 3.3.0-dev (rel)
Compiler: heads/master-0-g39d07abf36f7cad883d6be2a384a77c0c8aac040
Repo schema: 248cb6ce2d336c890fb26fd16690bf1b53b46994
Extension API: 20140829
The version of Nginx is:
nginx version: nginx/1.7.4
Some images load, and others don't. We're using timthumb for images, and I do see one error:
\nWarning: Is a directory in /home/user/shared/timthumb/index.php on line 90
If I run a curl from the command-line, I get the following result for an image, which means it's being seen as far as I can tell:
HTTP/1.1 200 OK
Content-Type: image/gif
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: HHVM/3.3.0-dev
CF-Cache-Status: HIT
CF-RAY: 16513733df33085c-IAD
Server: cloudflare-nginx
Date: Fri, 05 Sep 2014 08:56:47 GMT
Expires: Sun, 05 Oct 2014 08:56:47 GMT
Cache-Control: public, max-age=2592000
Set-Cookie: __cfduid=d6c188df6595a443200995301f0b707981409907407975; expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/; domain=.placehold.it; HttpOnly
Last-Modified: Fri, 19 Nov 2010 07:00:00 GMT
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
I have a separate test server with the same content/database running NGINX/PHP-FPM, and the only variable I can see that's different in the curl is that when I run the curl against the dev server running php-fpm, the result is Content-Type: image/jpeg. When I run it against HHVM I get Content-Type: image/gif.
I would think this is related to rewrite rules, but I'm not sure. I also just discovered this error here as well in exception.log:
2014-09-05T12:04:06+00:00 ERR (3): Warning: open(tcp://127.0.0.1:11211?persistent=1&weight=2&timeout=10&retry_interval=10/sess_dd885307c2ba602e5faa7020c9c7c038, O_RDWR) failed: No such file or directory (2) in on line 0
Any advice would be greatly appreciated.
I have created a custom API for Magento Enterprise 1.11. Calling the API through Soap v1 works fine on my local dev environment, however I am unable to make calls from my local environment to the remote environment.
Using PHP interactive shell on my localdev:
php > $client = new SoapClient(WSDL_URI,array('trace'=>1));
php > $client->login(API_USER,API_KEY);
php > var_dump($client->__getLastResponse());
string(538) "<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:Magento" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body><ns1:loginResponse><loginReturn xsi:type="xsd:string">f0eec73e49665aaf9cc4a6644fba5dc6</loginReturn></ns1:loginResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>
I have been able to do this successfully from the localhost, as well as between two local VMs running on my dev machine. I can also access the methods of my custom API without issue.
However, when I try to make a soap client to my remote test environment, I am able to create the client, but the call to $client->login(), or any subsequent call results in the following:
php > $client = new SoapClient(REMOTE_WSDL_URI,array('trace'=>1));
php > $client->login(API_USER,API_KEY);
PHP Warning: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://REMOTE_HOST/index.php/api/index/index/wsdl/1/' : failed to load external entity "http://REMOTE_HOST/index.php/api/index/index/wsdl/1/" in php shell code:1
Stack trace:
#0 php shell code(1): SoapClient->__call('login', Array)
#1 php shell code(1): SoapClient->login(API_USER, API_KEY)
#2 {main}
php > var_dump($client->__getLastRequestHeaders());
string(255) "POST /index.php/api/index/index/ HTTP/1.1
Host: REMOTE_HOST
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.3.18-1~dotdeb.0
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:Mage_Api_Model_Server_HandlerAction"
Content-Length: 550
php > var_dump($client->__getLastResponseHeaders());
string(840) "HTTP/1.1 500 Internal Service Error
Date: Mon, 11 Feb 2013 19:06:56 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.19-1~dotdeb.0
Set-Cookie: PHPSESSID=7uqrcmiv96hroubnb1uu7c7cm6; expires=Wed, 13-Feb-2013 01:06:56 GMT; path=/; domain=.REMOTE_HOST; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: CUSTOMER=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.REMOTE_HOST; httponly
Set-Cookie: CUSTOMER_INFO=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.REMOTE_HOST; httponly
Set-Cookie: CUSTOMER_AUTH=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.REMOTE_HOST; httponly
Content-Length: 468
Vary: Accept-Encoding
Connection: close
Content-Type: text/xml; charset=utf-8
php > var_dump($client->__getLastResponse());
string(468) "<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>WSDL</faultcode><faultstring>SOAP-ERROR: Parsing WSDL: Couldn't load from 'http://REMOTE_HOST/index.php/api/index/index/wsdl/1/' : failed to load external entity "http://REMOTE_HOST/index.php/api/index/index/wsdl/1/"
</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
When I hit //REMOTE_HOST/index.php/api/?wsdl I get the standard Magento WSDL.
The two environments are 99.99% identical:
Server version: Apache/2.2.16 (Debian) (both local dev and remote)
PHP 5.3.18 (local dev) 5.3.19 (remote host)
Apache/PHP configurations are the same.
Code base is identical
I have scoured the intewebs for clues, including:
http://www.magentocommerce.com/boards/viewthread/56528/
http://www.magentocommerce.com/wiki/5_-_modules_and_development/web_services/overriding_an_existing_api_class_with_additional_functionality#wsdl
Unable to connect to Magento SOAP API v2 due to "failed to load external entity"
Magento API SOAP-ERROR: Parsing WSDL: Couldn't load from '[url]/index.php/api/index/index/?wsdl=1' : Couldn't find end of Start Tag part line 56
http://www.magentocommerce.com/api/soap/introduction.html
I've tried the "Content-Length" header fix mentioned in the sedond-to-last link, and just about everything else I could think of... Stumped.
While you can load the WSDL URL (http://REMOTE_HOST/index.php/api/index/index/wsdl/1/) from your computer, your remote server can't contact itself via its REMOTE_HOST.
PHP's SoapServer object (used by Magento's implementation) needs to contact the WSDL to know which methods are exposed.
For reasons I've never been able to figure out, it's a common network configuration for a server to not have access to it's own DNS entries. Connect to your server via SSH and try running the following
curl http://REMOTE_HOST/index.php/api/index/index/wsdl/1/
My guess is you'll get a network timeout or a REMOTE_HOST unknown error. Fix your configuration so your server can access itself, and everything should start working.
You could try changing host DNS nameservers perhaps.
vim /etc/resolv.conf to add Google's 8.8.8.8, 8.8.4.4