NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Request

perske · Post by **perske** » Mon Jan 17, 2011 9:14 pm

With Firefox 3.6.13 + NoScript 2.0.9.3 + LiveHTTPHeaders 0.16, an automatic
refresh of a page by issuing a POST request as described below results in 400
Bad Request after the Apache server times out reading the request. The problem
does not occur if either NoScript or LiveHTTPHeaders is deinstalled.

The HTML page that wants to refresh itself contains:

<body onload="timerID=setTimeout('document.mainform.submit()',60000);">

and:

<form method="post" enctype="multipart/form-data" accept-charset="utf-8"
action="https://....." name="mainform"> ..... </form>

The problem occurres only if this form is posted due to the timeout, but not if
it is posted by clicking on any submit button of the form.

If I click on the reload button (with or without the shift key held down) when
the 400 Bad Request is displayed, the error occures again.

I have hacked my Apache server to intercept the decrypted SSL data stream
(output of SSL_read() in modules/ssl/ssl_engine_io.c) into a file for
debugging.

Without LiveHTTPHeaders, the request data stream reads:

##### Begin of interception #####
POST /perMail/cgi/test/permail/1295218173 HTTP/1.1
Host: testxsso.uni-muenster.de
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206
Ubuntu/10.04 (lucid) Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: https://testxsso.uni-muenster.de/perMai ... 1295218112
X-Behavioral-Ad-Opt-Out: 1
X-Do-Not-Track: 1
Content-Type: multipart/form-data;
boundary=---------------------------8685874676609981101567304409
Content-Length: 4670

-----------------------------8685874676609981101567304409
Content-Disposition: form-data; name="what"

refr
-----------------------------8685874676609981101567304409
..... and all the other input fields .....
-----------------------------8685874676609981101567304409--
##### End of interception #####

With LiveHTTPHeaders, the request data stream reads:

##### Begin of interception #####
POST /perMail/cgi/test/permail/1295218471 HTTP/1.1
Host: testxsso.uni-muenster.de
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206
Ubuntu/10.04 (lucid) Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-Behavioral-Ad-Opt-Out: 1
X-Do-Not-Track: 1
Referer: https://testxsso.uni-muenster.de/perMai ... 1295218410
##### End of interception #####

As you can see, the Referer line gets moved down and the Content-Type and
Content-Length lines are missing. Also missing are the separator line and all
post data. This causes the Apache server to wait for the separator line until
timeout.

This problem does not occur e.g. when both NoScript and Firebug are installed.
Because Firebug intercepts HTTP headers as well, I assume that LiveHTTPHeaders
and not NoScript makes something wrong hooking itself into Firefox. But it might
be a NoScript bug nevertheless and thus I think you should know of the problem;
and perhaps you have a chance to circumvent it.

(I have posted the same information as bug report on
<https://www.mozdev.org/bugs/show_bug.cgi?id=23626>.)

Thanks for looking into it.

Post by **Giorgio Maone** » Mon Jan 17, 2011 9:30 pm

Most likely LiveHTTPHeaders makes wrong assumptions on the headers order.

Does this happen in latest development build?
If it does, does the problem persist if you set the noscript.doNotTrack.enabled preference to false?

perske · Post by **perske** » Mon Jan 17, 2011 9:51 pm

Thanks for your quick response! Both questions: Yes, the problem persists.

perske · Post by **perske** » Mon Jan 17, 2011 10:41 pm

Even worse to analyze:
It now only happens sometimes, sometimes the document.mainform.submit() is successful.

Post by **Giorgio Maone** » Mon Jan 17, 2011 10:54 pm

perske wrote:Even worse to analyze:
It now only happens sometimes, sometimes the document.mainform.submit() is successful.

I suspect you can make it predictable by executing the following code between each submission:

Code: Select all

top.opener.noscriptOverlay.ns.__parent__.DNS._cache.reset()

If this happens, then likely LHH gets fooled by NoScript's internal redirection machinery, which is however legal: in other words, it makes wrong assumptions on how nsIHTTPChannel instances work.

Could you check whether replacing LHH with HttpFox shows the same behavior?

perske · Post by **perske** » Tue Jan 18, 2011 12:02 am

I just replaced <body onload="timerID=setTimeout('document.mainform.target="_self";document.mainform.submit()',<<refresh>>);"> with <body onload="top.opener.noscriptOverlay.ns.__parent__.DNS._cache.reset();timerID=setTimeout('document.mainform.target="_self";document.mainform.submit()',<<refresh>>);">

The error console reports "top.opener is null", and document.mainform.submit() is no longer called (probably due to this error).

How do I execute that code correctly?

perske · Post by **perske** » Tue Jan 18, 2011 12:03 am

( Sorry, <<refresh>> is a placeholder)

Post by **Giorgio Maone** » Tue Jan 18, 2011 8:50 am

perske wrote:How do I execute that code correctly?

Ooops, forgot to tell you: that code is meant to be ran in Tools|Error Console, because it's chrome-privileged.

perske · Post by **perske** » Tue Jan 18, 2011 9:56 pm

Giorgio Maone wrote:
perske wrote:Even worse to analyze:
It now only happens sometimes, sometimes the document.mainform.submit() is successful.
I suspect you can make it predictable by executing the following code between each submission:
Code: Select all
top.opener.noscriptOverlay.ns.__parent__.DNS._cache.reset()

Yes, exactly; as long as I executed that code (>= 10 tries), reload was successful. When I stopped executing that code, the 4th reload failed again.

Giorgio Maone wrote: If this happens, then likely LHH gets fooled by NoScript's internal redirection machinery, which is however legal: in other words, it makes wrong assumptions on how nsIHTTPChannel instances work.

Could you check whether replacing LHH with HttpFox shows the same behavior?

No, the problem occurres only withLiveHTTPHeaders, not with HttpFox. I'll add a pointer to this discussion to the LiveHTTPHeaders bug report. Thank you for your great help!

Post by **therube** » Tue Jan 18, 2011 11:52 pm

Linked: Bugzilla@Mozdev – Bug 23626 NoScript + LiveHTTPHeaders + document.mainform.submit() causes 400 Bad Request

InformAction Forums

NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Request

NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Request

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ

Re: NoScript+LiveHTTPHeaders+JS submit() causes 400 Bad Requ