400 Bad Request
Officially: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
When / Why: The request in the script may be badly formatted. The best thing to do is check if the request has any parameters that you have edited, of so check them by debugging.
HTTP 401 Unauthorised
Officially: The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
When / Why: Typically when load testing many users are generated from the same machine. In a Microsoft example the browser can use the current Windows logon credentials as credentials for the web site using NTLM. Therefore if the login is different as does not have the same authorisation as the original login (from the recording phase) during the execution the server may deny access with 401.
In the script you should use:
SetAuthentication(UserNameVariable,PasswordVariable,DomainVariable);
HTTP 403 Forbidden
Officially: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
When / Why: If you do not see the error when manually browsing but do see it when running a script check that the script is recent. If there has been aconfiguration change on the server you may see this message: For example if if at one time a server hosted the site and now no longer does so and can't or won't provide a redirection to the new location it may send a HTTP 403 back rather than a more meaningful message.
Check that authentication is correctly set up in the script - see HTTP 401.
Also check that the browser you are simulating is allowed as a security policy can ban certain types of traffic from a server.
HTTP 404 Not Found
When / Why: You may find that when interacted with manually the web site does not appear to throw any HTTP 404 messages.
When running a load test script you then may see 404's in the response codes. This can be because the object (probably a page component) that the tool requested does not exist on the server - it may be a .gif or a .js java script or similar that is referenced by the page yet does not exist on the server. In a browser this would simply appear as an empty image place holder in the case of an image for example, or in the case of a java script you may even see nothing if the java script is redundant. As the tool specifically requests the object (as the browser does) it will of course log the 404 message if the object cannot be found.
HTTP 407 Proxy Authentication Required
Officially: This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
When / Why: The script was probably captured with the browser already pointing to a proxy server set (see browser network settings). See the information on HTTP 401 for reasons why this might happen.
Typically it's best to avoid running a load test through a proxy server, especially if production load will not be routed through that proxy server. Ways to avoid the proxy server are to remove the part of the script that states use of the proxy server (often internal applications are available even while bypassing the proxy server), if that doesn't work - move the injection point to a location in the network where the proxy server can be bypassed (perhaps the same VLAN as the web server).
HTTP 500 Internal Server Error
Officially: The server encountered an unexpected condition which prevented it from fulfilling the request.
When / Why: You'll often see this after an HTTP POST statement and it usually means that the post statement has not been formed correctly.
There can be a number of reasons for this including the request being badly formed by the tool - or at least not formed as expected by the server. More typically it's because the POSTed form values are incorrect due to incorrect correlation / parameterisation of form variables.
For example: In a .Net application a very large __VIEWSTATE value is passed between the browser and server with each POST, this is a way to maintain state and puts the onus on state ownership on the browser rather than the server. This can have performance issues which I won't go into here. If this value is not parameterised correctly in the script (there can be more than one __VIEWSTATE) then the server can be confused (sent erroneous requests) and respond with a 500 Internal Server Error.
A 500 error usually originates from the application server part of the infrastructure.
It's not just .Net parameters that can cause this. Items such as badly formed dates, incorrectly formatted fields and badly formatted strings (consider replaced spaces with + characters) and so on can all cause HTTP 500 errors.
HTTP 503 Service Unavailable
Officially: The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
When / Why: Typically this will be due to the allowed number of concurrent connections on the server and is usually down to a configuration or license setting. For example IIS running on a non server version of Windows is limited to 10 concurrent connections - after this point it will deliver a 503 message. There is a temptation in load testing to overload the application under test, so it's worth revisiting your non functional requirements - will the production server ever see this number of concurrent connections?
Officially: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
When / Why: The request in the script may be badly formatted. The best thing to do is check if the request has any parameters that you have edited, of so check them by debugging.
HTTP 401 Unauthorised
Officially: The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
When / Why: Typically when load testing many users are generated from the same machine. In a Microsoft example the browser can use the current Windows logon credentials as credentials for the web site using NTLM. Therefore if the login is different as does not have the same authorisation as the original login (from the recording phase) during the execution the server may deny access with 401.
In the script you should use:
SetAuthentication(UserNameVariable,PasswordVariable,DomainVariable);
HTTP 403 Forbidden
Officially: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
When / Why: If you do not see the error when manually browsing but do see it when running a script check that the script is recent. If there has been aconfiguration change on the server you may see this message: For example if if at one time a server hosted the site and now no longer does so and can't or won't provide a redirection to the new location it may send a HTTP 403 back rather than a more meaningful message.
Check that authentication is correctly set up in the script - see HTTP 401.
Also check that the browser you are simulating is allowed as a security policy can ban certain types of traffic from a server.
HTTP 404 Not Found
When / Why: You may find that when interacted with manually the web site does not appear to throw any HTTP 404 messages.
When running a load test script you then may see 404's in the response codes. This can be because the object (probably a page component) that the tool requested does not exist on the server - it may be a .gif or a .js java script or similar that is referenced by the page yet does not exist on the server. In a browser this would simply appear as an empty image place holder in the case of an image for example, or in the case of a java script you may even see nothing if the java script is redundant. As the tool specifically requests the object (as the browser does) it will of course log the 404 message if the object cannot be found.
HTTP 407 Proxy Authentication Required
Officially: This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication"
When / Why: The script was probably captured with the browser already pointing to a proxy server set (see browser network settings). See the information on HTTP 401 for reasons why this might happen.
Typically it's best to avoid running a load test through a proxy server, especially if production load will not be routed through that proxy server. Ways to avoid the proxy server are to remove the part of the script that states use of the proxy server (often internal applications are available even while bypassing the proxy server), if that doesn't work - move the injection point to a location in the network where the proxy server can be bypassed (perhaps the same VLAN as the web server).
HTTP 500 Internal Server Error
Officially: The server encountered an unexpected condition which prevented it from fulfilling the request.
When / Why: You'll often see this after an HTTP POST statement and it usually means that the post statement has not been formed correctly.
There can be a number of reasons for this including the request being badly formed by the tool - or at least not formed as expected by the server. More typically it's because the POSTed form values are incorrect due to incorrect correlation / parameterisation of form variables.
For example: In a .Net application a very large __VIEWSTATE value is passed between the browser and server with each POST, this is a way to maintain state and puts the onus on state ownership on the browser rather than the server. This can have performance issues which I won't go into here. If this value is not parameterised correctly in the script (there can be more than one __VIEWSTATE) then the server can be confused (sent erroneous requests) and respond with a 500 Internal Server Error.
A 500 error usually originates from the application server part of the infrastructure.
It's not just .Net parameters that can cause this. Items such as badly formed dates, incorrectly formatted fields and badly formatted strings (consider replaced spaces with + characters) and so on can all cause HTTP 500 errors.
HTTP 503 Service Unavailable
Officially: The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
When / Why: Typically this will be due to the allowed number of concurrent connections on the server and is usually down to a configuration or license setting. For example IIS running on a non server version of Windows is limited to 10 concurrent connections - after this point it will deliver a 503 message. There is a temptation in load testing to overload the application under test, so it's worth revisiting your non functional requirements - will the production server ever see this number of concurrent connections?
HTTP Response Messages
HTTP servers respond to client requests in the form of a response message. This message contains a status line, response headers, and meta-information about the resource (information about the resource itself, not about the information that is contained in the resource).
Each HTTP status line contains the HTTP version number, a status code, and a description. For example, "HTTP/1.0 200 OK" is a typical status line returned in a response message from an HTTP server.
HTTP Status Codes
|
|
LoadRunner Training in Bangalore
LoadRunner Training in Hyderabad
LoadRunner Online Training
LoadRunner Training in BTM
LoadRunner Training in Marathahalli
Best LoadRunner Training Institutes in Bangalore
Best LoadRunner Training Institutes in India
Training Institutes in Bangalore
No comments:
Post a Comment