1500346 - POST method not work in simple form (replaced with GET)

Status: NEW

(Core :: Security: CAPS, defect, P3)

Description

[nexwo]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

(Firefox Quantum): Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 
Version: 60.2.2esr (32-bit)

Source url/server (where the simple html exists):
-Jenkins
-https://www.example.com:8443/subfolder/subfolder/subfolder/subfolder/subfolder/subfolder/file.html
-https on 8443
-HTTP/1.1

Extra headers (tried to solve):
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;
X-WebKit-CSP: default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;
X-Content-Security-Policy: default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;

Content on source: simple html without JavaScript:
<form action="https://www.example.com/subfolder/page" method="POST" target="_blank">
<input type="hidden" name="data" value="{&quot;json&quot;:&quot;test&quot;}">
<input type="submit" value="Update">
</form>

Target server:
-Apache
-https on 443
-HTTP/2.0

Extra headers (tried to solve):
access-control-request-method: POST, GET
access-control-allow-methods: POST, GET
access-control-allow-origin: *


Actual results:

Request method: GET (without params)
(new tab is opened)


Expected results:

Request method: POST
data=%7B%22json%22%3A%22test%22%7D
(new tab should be opened)

Comment 1

[nexwo]

Other info: HTML5 is used

Comment 2

[Rares Doghi, Desktop QA]

Hi Nexwo, Thanks for taking the time to report this issue, I managed to reproduce this issue in Nightly 65.0a1 (2018-10-23) , but I'm not sure if Networking is the correct component for it, if anyone can find a more suitable component please feel free to change it.

Please note that this issue might be related to Bug 1395002, if it's not please disregard the last Note.

Comment 3

[Honza Bambas (:mayhemer)]

nexwo, does https://www.example.com/subfolder/page redirect?  Does removing ` target="_blank"` from the form fix the problem?

Thanks.

Comment 4

[nexwo]

(In reply to Rares Doghi from comment #2)
> Hi Nexwo, Thanks for taking the time to report this issue, I managed to
> reproduce this issue in Nightly 65.0a1 (2018-10-23) , but I'm not sure if
> Networking is the correct component for it, if anyone can find a more
> suitable component please feel free to change it.
> 
> Please note that this issue might be related to Bug 1395002, if it's not
> please disregard the last Note.

This is a different problem.

Comment 5

[Honza Bambas (:mayhemer)]

(please see comment 3)

Comment 6

[nexwo]

I removed the 'target="_blank"' part, but it does not solve that. I pressed F12 to check the Network tab, but it not log that event.

Comment 7

[nexwo]

Redirect is not used at https://www.example.com/subfolder/page, so it just wait for POST request.

Comment 8

[nexwo]

It was worked well with "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0; Firefox 52.9.0 - 111712-1801120058-1.47"

Comment 9

[Honza Bambas (:mayhemer)]

OK, thank you!  Tthen I would like to ask you for logs according:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Start_logging_using_command_line_arguments

Feel free to send them (zipped) to my bugzilla email address.  Please mention the exact action URL that you expect to be requested with POST but we use GET instead.  Thanks.

Comment 10

[nexwo]

It is sent.

Comment 11

[Honza Bambas (:mayhemer)]

Nothing received.

Comment 12

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #11)
> Nothing received.

Maybe at spam?

Comment 13

[Honza Bambas (:mayhemer)]

of course checked that too.  Please, maybe use hbambas at mozilla com, or https://send.firefox.com/ instead.  Thanks.

Comment 14

[nexwo]

It is sent to the hbambas at mozilla dot com

Comment 15

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #14)
> It is sent to the hbambas at mozilla dot com

Thanks.  Now it was received.  Despite I have asked for a full log using command line args - this is only a main process snippet (apparently you used about:networking), I can confirm that redirects are not involved here.

OK, one possible cause is definitely ruled out.

Now I would like to ask for providing a minimal test case we could reproduce this with locally (some small php script set, perhaps.)

Comment 16

[nexwo]

I tried the console version but that did not make the log file. The test file/case will be sent tomorrow.

Comment 17

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #16)
> The test
> file/case will be sent tomorrow.

Thanks!

Comment 18

[nexwo]

Attachment: test_files_for_bug.zip

Files to reproduce the BUG.

Comment 19

[nexwo]

I try the test files without secure connection (without https) on 8080 and 80 ports and it is affected too.

Comment 20

[nexwo]

localhost and direct ip are NOT affected!
- http://localhost:8080/test.html -> http://localhost/report.php
- http://10.76.203.64:8080/test.html -> http://10.76.203.64/report.php

Comment 21

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #20)
> localhost and direct ip are NOT affected!
> - http://localhost:8080/test.html -> http://localhost/report.php
> - http://10.76.203.64:8080/test.html -> http://10.76.203.64/report.php

So, I should host the files somewhere else than on a local hosted server?  Can you please be more specific about how to use the test case?

Thank you!

Comment 22

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #21)
> So, I should host the files somewhere else than on a local hosted server? 
> Can you please be more specific about how to use the test case?
> 
> Thank you!

You need a domain name for the host in your private/public network what can be resolved by dns server. The host is local or another computer, does not matter.

Comment 23

[nexwo]

Attachment: bug_1500346_log.zip

Logs from Browser

Used:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Logging_HTTP_activity_by_manually_setting_environment_variables

Not work:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Start_logging_using_command_line_arguments
Issues: 
1. Use "c:\Program Files (x86)\Mozilla Firefox\firefox.exe" instead of "c:\Program Files\Mozilla Firefox (x86)\firefox.exe"
2. not logging to selected path

Comment 24

[nexwo]

I pressed F12 for check the Network tab, and I selected the "Persist Logs", but when I clicked on the Update Button, then the list is cleared and show this:

• Perform a request or [Reload] the page to see detailed information about network activity.
• Click on the [@] button to start performance analysis. (?)

Comment 25

[nexwo]

1. Test Case: 443 -> 8443
- Start Firefox
- Load https://pcname.area.area.company.ltd/test.html
- Click on Update
- https://pcname.area.area.company.ltd:8443/report.php is loaded with POST
- Close Firefox
Result: PASS, NOT affected!


2. Test Case: 8443 -> 443
- Start Firefox
- Load https://pcname.area.area.company.ltd:8443/test.html
- Click on Update
- https://pcname.area.area.company.ltd/report.php is loaded with GET
- Close Firefox
Result: FAIL, Affected!


3. Test Case: combined
- Run 1. test case (without close Firefox) - Success
- Run 2. test case - Success (sometimes)
Result: PASS (sometimes)

Comment 26

[nexwo]

4. Test Case: 8443 -> 9443
- Start Firefox
- Load https://pcname.area.area.company.ltd:8443/test.html
- Click on Update
- https://pcname.area.area.company.ltd:9443/report.php is loaded with POST
- Close Firefox
Result: PASS, NOT affected!

Comment 27

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #23)
> Not work:
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> HTTP_logging#Start_logging_using_command_line_arguments
> Issues: 
> 1. Use "c:\Program Files (x86)\Mozilla Firefox\firefox.exe" instead of
> "c:\Program Files\Mozilla Firefox (x86)\firefox.exe"
> 2. not logging to selected path

I don't understand the issue.  If you are using ESR it has probably a different install location, depending on your local machine.  You simply have to find it (can't help here).  The path to write the log to has to be pointing to a directory writable by the running (logged in) user.  There is no error reported anywhere if the log file can't be created.


I'm checking the test case now, thanks for it and the detailed description of steps!

Comment 28

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #27)
> I don't understand the issue.  If you are using ESR it has probably a
> different install location, depending on your local machine.  You simply
> have to find it (can't help here).  The path to write the log to has to be
> pointing to a directory writable by the running (logged in) user.  There is
> no error reported anywhere if the log file can't be created.
> 
> 
> I'm checking the test case now, thanks for it and the detailed description
> of steps!

The "c:\Program Files\Mozilla Firefox (x86)\firefox.exe" path is mistyped default path for 32 bit Windows.
When I try it, then it does not create log files in selected path, but it has all permission.

Comment 29

[Honza Bambas (:mayhemer)]

Thanks for comment 25.  I tried exactly that, hosting the files in a root folder of a secure local server (IIS) with a domain name in HOSTS file and a valid cert, http/2 enabled.  I have two separate content dirs, one for 443 and another one for 8443.  test.html properly modified to have action URL according comment 25 different when served from 443 and 8443.

Could not reproduce with a clean profile (default prefs and initially no cache) and the latest Firefox Nightly and ESR 60.3.0.

It doesn't make much sense to me why we should use GET in the seconds case so far...



Rares, you claim in comment 2 that you managed to reproduce the issue with Nightly, can you describe the exact steps?

Comment 30

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #28)
> (In reply to Honza Bambas (:mayhemer) from comment #27)
> > I don't understand the issue.  If you are using ESR it has probably a
> > different install location, depending on your local machine.  You simply
> > have to find it (can't help here).  The path to write the log to has to be
> > pointing to a directory writable by the running (logged in) user.  There is
> > no error reported anywhere if the log file can't be created.
> > 
> > 
> > I'm checking the test case now, thanks for it and the detailed description
> > of steps!
> 
> The "c:\Program Files\Mozilla Firefox (x86)\firefox.exe" path is mistyped
> default path for 32 bit Windows.
> When I try it, then it does not create log files in selected path, but it
> has all permission.

Ah!!  The command line arg has been introduced in later version.  It's written there ;)

Then please use:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Logging_HTTP_activity_by_manually_setting_environment_variables

Thanks.

Comment 31

[Rares Doghi, Desktop QA]

Hi, Going through these comments I realize that I may have misunderstood the steps from the description, I was under the impression that when you try to reach -https://www.example.com:8443/subfolder/subfolder/subfolder/subfolder/subfolder/subfolder/file.html it was suppose to create a POST method in the Network tab instead of GET, sorry for the confusion, this issue seems a lot more technical that I thought.

Please Disregard my previous comment.

Comment 32

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #29)
> Thanks for comment 25.  I tried exactly that, hosting the files in a root
> folder of a secure local server (IIS) with a domain name in HOSTS file and a
> valid cert, http/2 enabled.  I have two separate content dirs, one for 443
> and another one for 8443.  test.html properly modified to have action URL
> according comment 25 different when served from 443 and 8443.
> 
> Could not reproduce with a clean profile (default prefs and initially no
> cache) and the latest Firefox Nightly and ESR 60.3.0.
> 
> It doesn't make much sense to me why we should use GET in the seconds case
> so far...
> 
> 
> 
> Rares, you claim in comment 2 that you managed to reproduce the issue with
> Nightly, can you describe the exact steps?

New log files are sent: comment #18 (for comment #30)
I have a proxy maybe it can affect that, but in other browsers it work well.

(In reply to Honza Bambas (:mayhemer) from comment #29)
> It doesn't make much sense to me why we should use GET in the seconds case so far...
2. Test Case: 8443 -> 443
- Start Firefox
- Load https://pcname.area.area.company.ltd:8443/test.html
- Click on Update
- Actual: https://pcname.area.area.company.ltd/report.php is loaded with GET (Expected: https://pcname.area.area.company.ltd/report.php is loaded with POST)
Result: FAIL, Affected!

So when I use post form in HTML from custom port (8443 or 8080) to the default port (443 or 80) then It don't work well.

Comment 33

[nexwo]

(In reply to nexwo from comment #32)
> New log files are sent: comment #18 (for comment #30)
New log files are sent: comment #23 (mistype)

Comment 34

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #33)
> (In reply to nexwo from comment #32)
> > New log files are sent: comment #18 (for comment #30)
> New log files are sent: comment #23 (mistype)

Thanks!  Ok, maybe send to hbambas at mozilla as well.  Nothing arrived so far.

Comment 35

[nexwo]

I direct install the Firefox Quantum 63.0 (64-bit) (but that steps is not applicable for all PC in my company)
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
When I try the 2. Test Case, it is failed too

Comment 36

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #34)
> (In reply to nexwo from comment #33)
> > (In reply to nexwo from comment #32)
> > > New log files are sent: comment #18 (for comment #30)
> > New log files are sent: comment #23 (mistype)
> 
> Thanks!  Ok, maybe send to hbambas at mozilla as well.  Nothing arrived so
> far.

Ok, but it is attached to this bug! :D

Comment 37

[nexwo]

I direct install the another Firefox Quantum 60.3.0esr (64-bit) (but that steps is not applicable for all PC in my company)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
When I try the 2. Test Case, it is failed too

Comment 38

[nexwo]

For completeness:
- No need secure HTTPS connection to check the BUG (secure connection was the default setting at my host, but the BUG affect the http connection too).
- The Firefox has a setting: Automatic proxy configuration URL, the sent log contain that: http://subdomain.company.ltd/bp.pac
- Test case: POST method from 8080 to 80
-- Start Firefox
-- Load http://<selected domain>:8080/test.html
-- Click on Update and wait for load
-- Actual: http://<selected domain>/report.php is loaded with GET method without parameters (Expected: https://<selected domain>/report.php is loaded with POST method with parameters)

- Today, I created a special DNS settings for a domain: internal.nexwo.org, A record: 10.76.203.64 (internal/private ip)
- I tried that page: http://internal.nexwo.org:8080/test.html, I pressed Update and it work well (POST method with parameters is sent)
--- So, the http://internal.nexwo.org:8080/test.html (global domain), http://localhost:8080/test.html (localhost), http://10.76.203.64:8080/test.html (internal/private IP) are NOT affected.

- I tried with PC name: http://pcname:8080/test.html, but it works well too
- I tried the http://pcname.area.area.company.ltd:8080/test.html (from log) URL, but it doesn't work well (Firefox uset GET instead of POST)
-- Other browsers work well with the same setting (Automatic proxy configuration)

Comment 39

[nexwo]

Attachment: bp.zip

Sample for Automatic proxy configuration URL

Comment 40

[nexwo]

DNS settings in internal.nexwo.org is "A record 10.76.203.64", but when I load the http://internal.nexwo.org/test.html or http://internal.nexwo.org:8080/test.html and I check the F11/Network tab in Firefox, it show me: Remote address: 10.4.103.143:8080 (for both), SO when I tried internal.nexwo.org, then the proxy is used, AND when I tied http://pcname.area.area.company.ltd:8080/test.html then the remote address was 10.76.203.64, so the proxy is not used.
Please check the proxy settings (It is already attached to this BUG, bp.zip), and try with similar proxy settings.

Comment 41

[nexwo]

I modify the hosts file in Windows (append this):
10.76.203.64 0.area.company.ltd
I tried that: http://0.area.company.ltd:8080/test.html and it is affected too.

Comment 42

[nexwo]

I tried the Firefox ESR 52.9.0 (64-bit) (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0)
It work well!

Comment 43

[nexwo]

2018-10-26 14:48:30 >> I clicked on Update button at test.html
I think the BUG is there:

[...]
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [1] { handler=22914400 condition=0 pollflags=5 }
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [0] { handler=1E7E5C00 condition=0 pollflags=5 }
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport   calling PR_Poll [active=2 idle=0]
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport poll timeout: none
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport     timeout = -1 milliseconds
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport     ...returned after 0 milliseconds
2018-10-26 14:47:41.031000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Clear
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Read 1
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Read -1
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport STS poll iter
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [1] { handler=22914400 condition=0 pollflags=5 }
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [0] { handler=1E7E5C00 condition=0 pollflags=5 }
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport   calling PR_Poll [active=2 idle=0]
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport poll timeout: none
2018-10-26 14:47:41.032000 UTC - [2476:Socket Thread]: D/nsSocketTransport     timeout = -1 milliseconds
2018-10-26 14:48:30.694000 UTC - [2476:Main Thread]: D/nsHttp HttpChannelParent::CleanupBackgroundChannel [this=1CF9E710 bgParent=00000000]
2018-10-26 14:48:30.696000 UTC - [2476:Main Thread]: D/nsHttp Destroying HttpChannelParent [this=1CF9E710]
2018-10-26 14:48:30.696000 UTC - [2476:Main Thread]: D/nsHttp HttpChannelParent::CleanupBackgroundChannel [this=1CF9E710 bgParent=00000000]
2018-10-26 14:48:31.382000 UTC - [2476:Main Thread]: D/nsHttp nsHttpHandler::Observe [topic="net:current-toplevel-outer-content-windowid"]
2018-10-26 14:48:31.382000 UTC - [2476:Main Thread]: D/nsSocketTransport STS dispatch [09CABC60]
2018-10-26 14:48:31.382000 UTC - [2476:Main Thread]: D/nsSocketTransport PollableEvent::Signal
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport     ...returned after 50352 milliseconds
2018-10-26 14:48:31.382000 UTC - [2476:Main Thread]: D/nsSocketTransport PollableEvent::Signal PR_Write 1
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Clear
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Read 1
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Read -1
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport STS dispatch [09CE9340]
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport PollableEvent::Signal PR_Write 1
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: V/nsHttp nsHttpConnectionMgr::OnMsgUpdateCurrentTopLevelOuterContentWindowId id=200000001
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport STS poll iter
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [1] { handler=22914400 condition=0 pollflags=5 }
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport   active [0] { handler=1E7E5C00 condition=0 pollflags=5 }
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport   calling PR_Poll [active=2 idle=0]
2018-10-26 14:48:31.382000 UTC - [2476:Socket Thread]: D/nsSocketTransport poll timeout: none
[...]

Comment 44

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #40)
> DNS settings in internal.nexwo.org is "A record 10.76.203.64", but when I
..
> Please check the proxy settings (It is already attached to this BUG,
> bp.zip), and try with similar proxy settings.

I probably wont have cycles to play with this any time soon.

(In reply to nexwo from comment #42)
> I tried the Firefox ESR 52.9.0 (64-bit) (Mozilla/5.0 (Windows NT 10.0;
> Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0)
> It work well!

An interesting point.  If we broke this between 52 and 60, could you try to find the changeset that fails first using mozilla regression tool?  see [1].

Also, I would be kinda interested to see what the content of the test.html page that fails is (displayed with ctrl-u).  I want to eliminate a possibility that your proxy is messing with the html markup.

[1] https://mozilla.github.io/mozregression/


(In reply to nexwo from comment #43)
> 2018-10-26 14:48:30 >> I clicked on Update button at test.html

I have no idea what you are trying to show me here.

Comment 45

[nexwo]

I tried, but the Mozregression app doesn't have proxy settings and it doesn't work.

Comment 46

[nexwo]

Attachment: 2018-10-29_08h47_38.png

Mozregression error.

Comment 47

[nexwo]

I successful reproduced the error on localhost:

1. step: need host on 80 and 8080 port
2. host the test.html file on 8080 port
3. rewrite form action to 'action="http://localhost/report.php"'
4. In Mozilla about:config: append localhost to the 'capability.policy.localfilelinks.sites'
5. click on Update button at http://localhost:8080/test.html
6. see, the POST method does not work well

+ No need proxy
+ No need SSL connection
+ No need specific domain
+ If you append example.com to the 'capability.policy.localfilelinks.sites' then you can try http://subdomain.example.com:8080/test.html too, it won't work well

Comment 48

[nexwo]

Other settings (Maybe need):
capability.policy.localfilelinks.checkloaduri.enabled;allAccess
capability.policy.policynames;localfilelinks

Comment 49

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #48)
> Other settings (Maybe need):
> capability.policy.localfilelinks.checkloaduri.enabled;allAccess
> capability.policy.policynames;localfilelinks

Please try to find the minimal changes to preferences needed.

You didn't answer all questions in comment 44.

Based on this, I'm moving to CAPS.

Comment 50

[nexwo]

What is the open question?

Comment 51

[Honza Bambas (:mayhemer)]

(In reply to nexwo from comment #50)
> What is the open question?

>>> Also, I would be kinda interested to see what the content of the test.html page that fails is (displayed with ctrl-u).  I want to eliminate a possibility that your proxy is messing with the html markup.

Comment 52

[nexwo]

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<title>Test Page: Send</title>
	</head>
	
	<body>
		<form action="http://localhost/report.php" method="POST">
			<input type="hidden" name="data" value="{&quot;json&quot;:&quot;test&quot;}">
			<input type="submit" value="Update">
		</form>
	</body>

</html>

Comment 53

[nexwo]

I successful reproduced the error on localhost in LINUX:

1. step: need host on 80 and 8080 port (apache)
2. host the test.html file on 8080 port
3. rewrite form action to 'action="http://localhost/report.php"' in test.html what is attached in this bug
4. At Mozilla folder/prefs.js append this:
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
user_pref("capability.policy.localfilelinks.sites", "localhost");
user_pref("capability.policy.policynames", "localfilelinks");

5. start Firefox and load http://localhost:8080/test.html
6. click on Update button in page
7. see, the POST method does not work well (Firefox will load http://localhost/report.php page with GET instead of POST)

+ No need proxy
+ No need SSL connection
+ No need specific domain
+ That happened: 8080 -> 80, 8443 -> 443... (so when load a page at custom port and the page has a html form POST action with default port)

Comment 54

[nexwo]

If you press F12 to check what happening when you click on the Update button at http://localhost:8080/test.html, then Firefox looks like crashed and show nothing.

Comment 55

[nexwo]

(In reply to Honza Bambas (:mayhemer) from comment #51)
> (In reply to nexwo from comment #50)
> > What is the open question?
> 
> >>> Also, I would be kinda interested to see what the content of the test.html page that fails is (displayed with ctrl-u).  I want to eliminate a possibility that your proxy is messing with the html markup.

Just misunderstandig, I pressed F12 to check remote address of the loaded page.

Comment 56

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.