Http redirect launches new browser window

delphi package - automated exception handling
Post Reply
slemmnord
Posts: 46
Joined: Fri Jan 17, 2014 1:04 am

Http redirect launches new browser window

Post by slemmnord »

Hi!

Recently i upgraded our web server to use SSL. I also added rule in Apache config to upgrade all non-https connections using mod_rewrite (it returns code 302 with new location parameter).

It turns out, madExcept does not handle such redirects well. I have ME set to post data to php script. Of course all the previous versions of our software was still using http:// as the address and got redirected. The resulting behavior was that my app opened a new browser window (whichever is system default) with text "invalid password" (returned by the bugrep php script) and then nothing. Leaving users with impression they had sent the report.

I've of course modified the redirect rule on server for now to make an exception for bug reports and changed the report url in ME settings to submit directly on https.

However:
- if you are ME user and upgrading your web server (or moving your bug reporting to another URL), you might want to consider this
- if you are Mathias and making a new version of ME, you might want to look into how 302 is handled :P

Cheers and a bit late happy new year to everyone!
BarryStaes
Posts: 35
Joined: Wed Dec 14, 2011 8:13 am

Re: Http redirect launches new browser window

Post by BarryStaes »

I had the same problem (302 not supported by madexcept) after upgrading MantisBT;
viewtopic.php?f=4&t=27945&hilit=302+301
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Http redirect launches new browser window

Post by madshi »

Does setting the following var (exported by madExcept.pas) make it work?

Code: Select all

var EnableRedirection : boolean = false;  // should WinHTTP do all HTTP redirection work for us?
slemmnord
Posts: 46
Joined: Fri Jan 17, 2014 1:04 am

Re: Http redirect launches new browser window

Post by slemmnord »

Nope, unfortunately that does not help either. Now it wont open browser window and doesn't complain and doesn't deliver the report either.

From Apache logs:

Code: Select all

IP.IP.IP.IP - - [31/Jan/2017:01:33:02 +0X00] "POST /bugrep.php HTTP/1.1" 302 212
IP.IP.IP.IP - - [31/Jan/2017:01:33:02 +0X00] "GET /bugrep.php HTTP/1.1" 401 7
IP.IP.IP.IP - - [31/Jan/2017:01:33:02 +0X00] "GET /bugrep.php HTTP/1.1" 200 -
The first line shows client is using POST method (correct) and gets reply 302 (redirect). The client now tries again using GET method (wrong!) and receives back code 401 which means no authentication info was provided in the request (meaning no user&password was sent). The third and last line is again retry with GET method and this time user+pass was provided. However since the method has morphed into GET, the bugrep.php rejects the report silently.

Trying first without login info and only sending it in response to 401 seems to be normal behavior of WinHTTP.
Here is successful reporting log:

Code: Select all

IP.IP.IP.IP - - [31/Jan/2017:02:43:26 +0X00] "POST /bugrep.php HTTP/1.1" 401 7
IP.IP.IP.IP - - [31/Jan/2017:02:43:26 +0X00] "POST /bugrep.php HTTP/1.1" 200 -
I've improved the bugrep.php a little bit to send back error status instead of ok (200) on GET method.

Original:

Code: Select all

if (($found) || (isset($_POST['MailSubject'])) || (isset($_POST['MailBody'])))
{
  // we've found an attachment, or at least the mail subject or body was set
  // so we send the email
  if (!$mailer->Send())
    header('HTTP/1.0 500 Mailing failed');
}
Improved:

Code: Select all

if (($found) || (isset($_POST['MailSubject'])) || (isset($_POST['MailBody'])))
{
  // we've found an attachment, or at least the mail subject or body was set
  // so we send the email
  if (!$mailer->Send())
    header('HTTP/1.0 500 Mailing failed');
} else
{
  if ($_SERVER['REQUEST_METHOD']!='POST') {
    header('HTTP/1.0 500 Bad request method');
  } else {
    header('HTTP/1.0 500 No report received');
  }
}
A little research turns out that this Winhttp behavior of morphing POST to GET is a known buggy behavior and intentionally maintained for compatibility. See here.

GET method is not suitable for sending bug reports text and screenshot. This rules out changing the php script to work with both GET and POST and i think leaves only one option - to keep WinHTTP from following redirects automatically and instead handle the redirection case in ME by resubmitting POST request to new address.

I have my case solved long ago. But in my opinion correct handling of redirection is important. Domain names can change, file names on server can change, companies get bought, etc. But old software released earlier that still reports to old address...
slemmnord
Posts: 46
Joined: Fri Jan 17, 2014 1:04 am

Re: Http redirect launches new browser window

Post by slemmnord »

I'm attaching my complete php script. I have made some (useful imo) modifications over the version you have posted here. Also you are hosting a very old version (http://madshi.net/bugRepMailer.zip) which is linked from the forum.

- removed basic authentication as it's very insecure
- disabled spoofing of sender email because today SPF is starting to be widely used. instead using reply-to for reporter email.
- added handling for wrong method and empty report

Sorry, had to zip the file because phpbb rejected most file name extensions.
Attachments
bugRepMailer2.zip
(2.08 KiB) Downloaded 302 times
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: Http redirect launches new browser window

Post by madshi »

Thanks for the updated PHP script, I'll have a look at your changes later and hopefully integrate them into my help/sources.

About redirection here's something I posted in the thread Barry mentioned earlier. It's still valid:
The key problem for me with this redirection is that madExcept has always supported a redirect in a different way: Basically when you do an HTTP upload and the server replies with a redirect, madExcept will open the redirection URL in a web browser. The purpose of this logic is that this way you can provide the user with feedback, e.g. you can create a custom webpage and let the user know that the bug is already known and can be worked around by installing a service pack, or something.

Now that you mention your situation, of course it would also make sense to support redirection in that sense that madExcept would accept a redirect to another mantis server URL. However, the whole HTTP upload class used by madExcept depends on the URL being known right from the start. The way it's written it can't handle redirection to a different URL. What I could do is free the whole HTTP upload class and recreate it with the new URL, but that's not really nice and would require me to add the same code everywhere I use the HTTP upload class, so the code footprint would increase by a certain amount.
slemmnord
Posts: 46
Joined: Fri Jan 17, 2014 1:04 am

Re: Http redirect launches new browser window

Post by slemmnord »

I do not use Mantis myself so i'm not sure what it replies when similar bug is already registered. Perhaps that response could be further analyzed (such as the message part associated with the redirect code) to determine if browser should open* or redirect followed and report posted again. Also this is relevant for Mantis (and Bugzilla?) but not with the php script.

At the same time i do think it's useful to have some way to send a message back to user. Either to say "Thank you, your report has been received" or "Stop reporting that dumb-ass, we already know about this bug".. or whatever. Perhaps agree on special (standard or non-standard) response code that wont confuse WinHTTP? And a callback to the application where developer could decide if he wants to show dialog with the received message or open browser window or whatever. Oh.. or retry posting on redirect URL?

* the surprising event that my app was attempting to launch a web browser did make my brow raise.
Post Reply