What does the following format signifies?
"GET /shipments HTTP/1.1" 200 1339
GET is the type of request
/shipments is the url hit
200 is the status code
What are HTTP/1.1 and 1339
In your example, HTTP/1.1 is the HTTP version the client used to make its request, and 1339 the length of the response in bytes.
Check out the documentation for the mod_log_config for a list of all the variables that can be used in log files.
Related
A normal log looks like this:
111.111.111.111 222.222.222.222 - - [06/Jun/2017:02:19:00 +0900] "GET /monitor/l7check.nhn HTTP/1.1" 200 4 1222 "-" "-"
but some log looks like this:
111.111.111.111 333.333.333.333 - - [06/Jun/2017:02:18:58 +0900] "-" 408 - 13 "-" "-"
I can't understand the meaning of this log.
Why does it have only a 'dash' instead of a 'get URL'?
Is it possible to log to a URL without requesting a URL?
https://www.rfc-editor.org/rfc/rfc7231#section-6.5.7
6.5.7. 408 Request Timeout
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.
So, the client connected, but did not send any HTTP request. The server waited, and eventually closed the connection.
I've followed the steps provided in https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/protecting-external-resources/ to protect an external resource and https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/application-development/resource-request/javascript/ to call via Cordova.
I'm making 2 request to the same REST method, which is protected with the scope "aovLogin".
It seems that every call is generating a new bearer token, which needs 4 extra calls to MFP.
Also, the first time a method is called, it makes several extra calls (it always goes http 401, then 403 then 200, making extra calls to MFP in the middle). If i have a very granular API, it's making a lot of extra calls.
I've seen that the server API has a cache for the bearers and the scope is configured for being valid for 10 minutes.
Why is the client sending so many authorization requests?
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
HTTP/1.1 401 Unauthorized
----------
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"","client_id":"3deccec7-3f18-4ee2-8464-de90a7c64685"}
HTTP/1.1 400 Bad Request
{"errorCode":"INVALID_CLIENT_ID","errorMsg":"Invalid client ID."}
------
POST /mfp/api/registration/v1/self HTTP/1.1
{"signedRegistrationData":{"header":"XXXXX","payload":"XXXXX","signature":"XXXXX"}}
HTTP/1.1 201 Created
-----
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 200 OK
{"successes":{"clockSynchronization":{"serverTimeStamp":1480322130967}}}
--------
GET /mfp/api/az/v1/authorization?response_type=code&scope=&client_id=84c45e4a-b75d-4125-ab9a-98f390d5bd3a&redirect_uri=http://mfpredirecturi&isAjaxRequest=true&x=0.1757133661526875 HTTP/1.1
HTTP/1.1 302 Found
------
POST /mfp/api/az/v1/token HTTP/1.1
XXXXX
HTTP/1.1 200 OK
{"access_token":"XXXXX","token_type":"Bearer","expires_in":3599,"scope":""}
---
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer XXXXX
{"idDelegation":"0801"}
HTTP/1.1 403 Forbidden
---
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"aovLogin","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 401 Unauthorized
{"successes":{"clockSynchronization":{"serverTimeStamp":1480322131320}},"challenges":{"aovLogin":{"remainingAttempts":5,"errorMsg":null}}}
---
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"challengeResponse":{"aovLogin":{"username":"XXXXX","tokenSEA":"XXXXX"}},"scope":"aovLogin","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 200 OK
{"successes":{"aovLogin":{"user":{"id":"XXXXX","displayName":"XXXXX","authenticatedAt":1480322139874,"authenticatedBy":"aovLogin","attributes":{"tokenSEA":"XXXXX"}}},"clockSynchronization":{"serverTimeStamp":1480322139874}}}
--------
GET /mfp/api/az/v1/authorization?response_type=code&scope=aovLogin&client_id=84c45e4a-b75d-4125-ab9a-98f390d5bd3a&redirect_uri=http://mfpredirecturi&isAjaxRequest=true&x=0.5223292209780417 HTTP/1.1
HTTP/1.1 302 Found
---
POST /mfp/api/az/v1/token HTTP/1.1
XXXXX
HTTP/1.1 200 OK
{"access_token":"XXXXX","token_type":"Bearer","expires_in":599,"scope":"aovLogin"}
---
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6Ijg0YzQ1ZTRhLWI3NWQtNDEyNS1hYjlhLTk4ZjM5MGQ1YmQzYSIsIm4iOiJBTTBEZDd4QWR2NkgteWdMN3I4cUNMZEUtM0kya2s0NXpnWnREZF9xczhmdm5ZZmRpcVRTVjRfMnQ2T0dHOENWNUNlNDFQTXBJd21MNDEwWDlJWm52aHhvWWlGY01TYU9lSXFvZS1ySkEwdVp1dzJySGhYWjNXVkNlS2V6UlZjQ09Zc1FOLW1RSzBtZno1XzNvLWV2MFVZd1hrU093QkJsMUVocUl3VkR3T2llZzJKTUdsMEVYc1BaZmtOWkktSFU0b01paS1Uck5MelJXa01tTHZtMDloTDV6b3NVTkExNXZlQ0twaDJXcG1TbTJTNjFuRGhIN2dMRW95bURuVEVqUFk1QW9oMmluSS0zNlJHWVZNVVViTzQ2Q3JOVVl1SW9iT2lYbEx6QklodUlDcGZWZHhUX3g3c3RLWDVDOUJmTVRCNEdrT0hQNWNVdjdOejFkRGhJUHU4PSJ9fQ.eyJpc3MiOiJjb20uaWJtLm1mcCIsInN1YiI6Ijg0YzQ1ZTRhLWI3NWQtNDEyNS1hYjlhLTk4ZjM5MGQ1YmQzYSIsImF1ZCI6ImNvbS5pYm0ubWZwIiwiZXhwIjoxNDgwMzIyNzM5ODc0LCJzY29wZSI6ImFvdkxvZ2luIn0.jGJAhZaV6NFHZKj-LKBmJ6Gqb7ZrZX20xDKEPkNtORZ1tanLo8MSklY2HogK-wKs7APIuWESLSsskrwR9p0EnrmHgUYZf3BPY9HDUSBojUN9-vd_I9kavcg34Hes1KTvYG4Wi-9XbZQ2T1-SbHhn-mqsToeLIGBGkzsugwQG9tIKG3Qr0BixDIfuhxux4Gdo30HCyn9SB5ZaY5wdxaD2_kJjnJih_SsAuuXRNAXEO_PgExnZ6Mr1qyqyOfwc3k9jmgRpuEQigYYRYOP-Tvs_i59IVYOdpsQ70gi-Ky09orx5Jy3hVJv-J45Dx7FHdR3ZPTn7pYW7IRmRo4CZ2COoCg
HTTP/1.1 200 OK
.....
--- CALL AGAIN, new bearer is generated
POST /mfp/api/az/v1/introspection HTTP/1.1
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
GET /mfp/api/az/v1/authorization?XXX HTTP/1.1
POST /mfp/api/az/v1/token HTTP/1.1
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6IjM1NDcyYWNhLWVlNmItNGNhZi04OGQ2LWQxY2ExNjQ0NzM4NyIsIm4iOiJBTTBEZDd4QWR2NkgteWdMN3I4cUNMZEUtM0kya2s0NXpnWnREZF9xczhmdm5ZZmRpcVRTVjRfMnQ2T0dHOENWNUNlNDFQTXBJd21MNDEwWDlJWm52aHhvWWlGY01TYU9lSXFvZS1ySkEwdVp1dzJySGhYWjNXVkNlS2V6UlZjQ09Zc1FOLW1RSzBtZno1XzNvLWV2MFVZd1hrU093QkJsMUVocUl3VkR3T2llZzJKTUdsMEVYc1BaZmtOWkktSFU0b01paS1Uck5MelJXa01tTHZtMDloTDV6b3NVTkExNXZlQ0twaDJXcG1TbTJTNjFuRGhIN2dMRW95bURuVEVqUFk1QW9oMmluSS0zNlJHWVZNVVViTzQ2Q3JOVVl1SW9iT2lYbEx6QklodUlDcGZWZHhUX3g3c3RLWDVDOUJmTVRCNEdrT0hQNWNVdjdOejFkRGhJUHU4PSJ9fQ.eyJpc3MiOiJjb20uaWJtLm1mcCIsInN1YiI6IjM1NDcyYWNhLWVlNmItNGNhZi04OGQ2LWQxY2ExNjQ0NzM4NyIsImF1ZCI6ImNvbS5pYm0ubWZwIiwiZXhwIjoxNDgwMzM5OTU0NjE2LCJzY29wZSI6ImFvdkxvZ2luIn0.JSm3nrW6BD5i66GossHYM4-6GqQfC-ZSH5P-X4M9mws2jBNvCkFKgv_XbRAb3km-0NMZz3FHsrY_0h0dx7fpJYiR9CIjaY-PFw75zdKbyEpzbhAX7OjZtYOtZblKEYLkT8mH-0mLc6VE_YBPFd2q55HMmECCLirAAdWwzMGgEzL02OKTd1GVuJyjqjlxeOJypFglaHezuByd6eGVMFJvnfDX3h_o6k8sWcv-g7UFa8jtcMNZpbzFOYG9Q2nGQ-oYIt17QyF4CVKPMN4anMwRRQ_2cjuvg-1ZuU450hxBX3u09wBxJ21mQklgg72t7fdLKgT7EIPmQlPP3wrX9qzy7A
HTTP/1.1 200 OK
Update:
The HTTP 401 and 403 calls to the external resource and serveral calls to MFP can be avoided if the scope is send in WLResourceRequest
It generates a new token calling an external resource using an absolute URL but also calling a standard protected adapter using a relative URL
Sample calling a protected adapter:
var resourceRequest = new WLResourceRequest(
"/adapters/AOS42_AOV_API/resource/protectedResource",
WLResourceRequest.GET,
{'scope' : 'aovLogin'} // it avoids 401 and 403 responses
);
resourceRequest.send().then(
function (response) {
alert("response ok protectedResource " + response.responseText);
},
function (response) {
alert("response ko protectedResource " + response.responseText);
}
);
Sample calling an external resource:
var resourceRequest = new WLResourceRequest(
"https://someurl.com/someApp/protectedResource",
WLResourceRequest.GET,
{'scope' : 'aovLogin'} // it avoids 401 and 403 responses
);
Update 2:
We've made a change: Instead of calling to a protected external resource, receiving HTTP 401 and then sending the challenge, now we call to WLAuthorizationManager.login before.
In Android, it continues calling MFP 3 times before each call, but now the server returns the same Bearer Token.
The same Cordova Application calling the same Rest API protected by MFP and using the same security adapter in MFP works perfectly fine in iOS.
Once the bearer is obtained, we see only calls to the external API.
This bug has been resolved in a just-released iFix for MobileFirst Foundation 8.0. The build number is 8.0.0.0-IF20170125-0919. Please login to IBM Fix Central to download the iFix.
The associated APAR is:
PI74988 MULTIPLE AUTHORIZATION CALLS ARE MADE FOR EACH REST CALL IN ANDROID APPLICATION
Since you're using Cordova, I believe updating the cordova-plugin-mfp plug-in to #8.0.2017012210 should suffice.
I'm calling a PHP API located on the same host of the API manager using a published API.
The client application is SoapUI or curl.
I issue the call and it gets passed to the httpd server that return:
curl -H "Authorization: Bearer Q7Eb8k6oUBe6O4nP10sEgzZREMMa" --url "http://10.1.1.141:8280/accident/v1/v1/accident.json"
10.1.1.141 - - [07/Feb/2013:12:41:41 +0100] "GET http://apman2.cortile.cloudlabcsi.local/restTest.php/v1/accident.json HTTP/1.1" 404 514 "-" "Synapse-HttpComponents-NIO"
curl http://apman2.cortile.cloudlabcsi.local/restTest.php/v1/accident.json
10.1.1.157 - - [07/Feb/2013:12:41:36 +0100] "GET /restTest.php/v1/accident.json HTTP/1.1" 200 120 "-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2"
Obviously The first is a call to the final API that WSO2 publishes with its own publish URL so the resulting call is made by Synapse-HttpComponents-NIO: curl call API-Manager and it uses Synapse-HttpComponents-NIO to call the PHP API.
The second is the same call issued directly from curl to the PHP API.
Logs are from HTTPD.
It's evident that the httpd receives the call
I cannot understand why Synapse-HttpComponents-NIO client get a 404 whils curl get the correct results.
Thanks
Luca
I have following problem with site http://huti.ru. When trying to add any of its pages in http://webmaster.yandex.ru/addurl.xml (Yandex - russian search engine) wrote "The server returns a status code http 405 (expected code 200)." What can caouse such different behevior for brawusers and yandex crawler? (Google indexes like normal)
Enviroment: tomcat, java 6
Your server does not allow HEAD requests. Seems that the robot first tries a HEAD before the actual GET.
As
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
states: HEAD should be identical to GET, except that it does never return a message body, but only the response headers for a particular request.
Note: I did a simple
HEAD / HTTP/1.0
request. Same with HTTP/1.1 + Host: huti.ru.
Check your server logs for the actual content of the response to the Yandex request.
HTTP 405 is Method Not Allowed, and is usually returned if the user agent has used an HTTP verb not supported for the particular resource.
For example, using Fiddler, I issued several requests to http://huti.ru, and I got 200 response for the HEAD, GET, and POST, but I got 405 for the TRACE. It's conceivable that Yandex issues either TRACE or OPTIONS, before making a request for the actual page as a form of a ping to determine if the page exists.
Note: #smilingthax mentioned that your server returns 405 on HEAD. However, issuing the following request from Fiddler worked for me:
HEAD http://huti.ru/ HTTP/1.1
Host: huti.ru
Proxy-Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.23 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Thus, your problem might be specific to HEAD requests with particular headers.
I think that 405 means that the page has already been indexed.
We have an Tomcat server where we're trying to log the HTTP version which the response is sent with. We've seen a few times that it seems to be HTTP/0.9, which kills the content (not supported I guess?). We would like to get some stats on this by using the access log in apache. However, since the header line for this isn't prefixed by anything, we cannot use the %{xxx}o logging.
Is there a way to get this?
An example:
Response is:
HTTP/1.1 503 This application is not currently available
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1090
Date: Wed, 12 May 2010 12:53:16 GMT
Connection: close
And we'd like the catch HTTP/1.1 (alternatively, HTTP/1.1 503 This application is not currently available.
Is this possible? We do not have access to the application being served, so we need to do this either as a Java filter, or in the tomcat access log - Preferably in the access log.
Enabling the <Valve className="org.apache.catalina.valves.RequestDumperValve"/> in server.xml writes out the request and response headers for each request.
Example:
19-May-2010 12:26:18 org.apache.catalina.valves.RequestDumperValve invoke
INFO: protocol=HTTP/1.1