Open Bug 1532448 Opened 6 years ago Updated 3 years ago

Developer Network console displays wrong GET request

Categories

(DevTools :: Netmonitor, defect, P3)

60 Branch
defect

Tracking

(Not tracked)

People

(Reporter: u20230201, Unassigned)

Details

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

Steps to reproduce:

While debugging a problem with an href-URL that contained literal spaces (like "Program Files"), I found a bug in the Developer Network Console: I was expecting the GET that received an empty response, and eventually I had been displaying the request headers.
Version used was Firefox 60.5.2 (ESR) 32-bit on Windows 7, using the Mozilla build.

Actual results:

In the GET request header the URL did not contain any spaces, but "%20" instead. However the request being sent DID actually contain non-encoded spaces!
(The proof was to copy the page source and replace all spaced in the href-URLs with "%20": Then the program received a valid response which it did not before)

Expected results:

The GET header should show the header that was sent actually, not an encoded version of it. The purpose of the header display is to find bugs, and showinf a value that is not being ´sent actually, does not help finding bugs!

In comment #0: s/I was expecting the GET/I was inspecting the GET/ # Sorry!

(In reply to Ulrich Windl from comment #0)

Version used was Firefox 60.5.2 (ESR)

Please check if the issue is reproducible in the latest Nightly in a brand new profile.
https://support.mozilla.com/kb/profile-manager-create-and-remove-firefox-profiles
https://www.mozilla.org/firefox/nightly/all/

Component: Untriaged → Netmonitor
Flags: needinfo?(Ulrich.Windl)
Product: Firefox → DevTools

This feels like dup of bug 1491008, correct?

Honza

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) from comment #3)

This feels like dup of bug 1491008, correct?

No I think it's the other way around. Maybe fixing the above even causes this error.
In my case a href like "Program Files" in the source was displayed as "Program%20Files" in the monitor, when actually "Program Files" was sent. Otherwise I could not explain what was going on.

Flags: needinfo?(Ulrich.Windl)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.