New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


HTTP Transaction Sensor: Problem with Redirects

Votes:

0

Your Vote:

Up

Down

I have simple scenario: I want to manage a website's response time for posting data typed into a form. There are 4 steps:

1. GET login.html 2. POST credentials.html 3. POST data.html 4. GET logout.html

These steps are quite easy to setup, however, on authentication (step 2) the server responds with a HTTP redirect (HTTP status code 302). This is a very common behavior in modern web applications, but PRTG regards this as an error; skipping the transaction.

I believe this handling is wrong since HTTP 3xx Redirection codes aren't errors.

Is there a way to accomplish this scenario or am I doing any mistakes?

302 http http-transaction-sensor redirect status

Created on Jan 10, 2012 3:14:28 PM by  beanformer (0) 1



8 Replies

Votes:

0

Your Vote:

Up

Down

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.

Created on Jan 11, 2012 1:02:27 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.

Created on Jan 11, 2012 4:32:38 PM by  beanformer (0) 1

Last change on Oct 25, 2018 7:12:55 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Jan 11, 2012 6:00:41 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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:

https://test.salesforce.com/login.jsp?un=x&pw=y

which returns a 302 Redirect to:

https://csZ.salesforce.com/home/home.jsp

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).

Created on Mar 8, 2012 11:50:24 AM by  Andy (0)

Last change on Oct 25, 2018 7:13:22 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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.)

Created on Mar 8, 2012 3:08:46 PM by  Andy (0)



Votes:

0

Your Vote:

Up

Down

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

Created on Mar 8, 2012 3:48:04 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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).

Created on Mar 9, 2012 3:56:13 PM by  Andy (0)



Votes:

0

Your Vote:

Up

Down

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

https://ssourl/?returnurl=https://successfullloginurl

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?

Created on Mar 25, 2012 6:19:19 PM by  xsane (0) 1

Last change on Oct 25, 2018 7:14:24 AM by  Luciano Lingnau [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.