HTTP Transaction Sensor: Problem with Redirects

Hello,

if a Redirect shows up as an error in the sensor, it's usually because of the redirect couldn't been resolved, due to another redirect from the target page or something similar. This may be caused by the user agent of PRTGs HTTP sensors or due to script code not being executed.

best regards.

Hi,

taking your tip into consideration, I tried to set the user agent manually, but that seems to be an option for the extended HTTP sensor only. Interestingly, in this case no error was reported.

Then i drilled down network communication with firebug: Response to posting credentials is

HTTP/1.1 302 Moved Temporarily
Location   https://www.cscc.imise.uni-leipzig.de/OpenClinica/MainMenu
...

which is correct. The next request is, not surprisingly:

GET https://www.cscc.imise.uni-leipzig.de/OpenClinica/MainMenu
Referer   https://www.cscc.imise.uni-leipzig.de/OpenClinica/pages/login/login

and response: HTTP/1.1 200 OK

So, there are no further redirects or script code.

I'm afraid then it seems the page does not 'like' the user agent of the HTTP Transaction sensor.

I too am having the same problem (and there is another person with the same problem here)

In my case, we're trying to check connectivity to Salesforce, using a request URL like:

which returns a 302 Redirect to:

However, both the HTTP Advanced and HTTP Transaction sensors log this as an error.

A bit like the above poster, I traced it using Wireshark, and I can see that the sensor is attempting to follow the redirect, but I don't believe that the user agent is causing the issue.

I wondered whether the problem is that the 302 redirect response from the login request to the server was setting a cookie, but then the sensor is not presenting it back when it follows the redirect. This would obviously fail authentication and lead to a second, failed, response (although why PRTG doesn't log this response, rather than the original 302 response, as the failure I don't know).

Further to my previous reply, I've run a quick test on a local site that works with login/redirect cookies in this way and the HTTP sensors are behaving as you'd expect.

The differences between the test (that works) and the live (that doesn't) are:

• the use of HTTPS (rather than HTTP)
• the redirect changing the hostname (albeit within the same domain)
• and a Proxy server sitting between the sensor and the site.

Any ideas if any of those are the cause of the issue?

(It would help to debug this if the sensor logged the content of the failed request rather than the 302.)

Redirects should be avoided on the HTTP Sensors in PRTG, please try entering the final site where the redirect 'ends'.

Hi Torsten

In this case, the redirect is actually the functionality that needs to be checked. It's not possible to go direct to the 'end' of the redirect because the correct functionality of the login URL is to authenticate the user, set a cookie and then redirect to the final destination. Going to the end of the redirect would skip the authentication step and so that request would definitely fail. Hence the numerous people trying to attempt this approach and finding a problem.

It is, however, not as simple as redirects not working, as my simpler, local test showed the redirects being followed correctly by the sensor. There is something deeper going on. Is there any way of switching on some debug logging for the sensor to see where the error is really occurring?

You should easily be able to reproduce my problem by signing up for a free Salesforce developer account and testing the exact same login process as I'm testing (albeit possibly without the proxy).

I am having the same problem. The http transactions that used to work before are now showing an error with 302. The transaction steps are

If I just use https://successfullloginurl it doesnt work either. What was changed with the http transaction monitor in 9 that these are now showing as errors?