Fiddler Ideas

The free web debugging proxy for any browser, system or platform.

Bug in the hyperlinks in the raw inspector

When crawling a site using Wget and Fiddler as a proxy, the hyperlinks created in the raw inspector are not correct, they include the HTTP/1.1 in the URL

 

GET http://www.telerik.com/aspnet-mvc HTTP/1.1
Referer: http://www.telerik.com/
User-Agent: Wget/1.19.1 (mingw32)
Accept: */*
Accept-Encoding: identity
Host: www.telerik.com
Connection: Keep-Alive

...

The HEX view looks good and there's a space between the URL and HTTP/1.1

To demonstrate the bug I ran this WGET command against telerik site to reproduce the error on a public site

wget -r -p -k -e use_proxy=on -e http_proxy=127.0.0.1:8888 -e https_proxy=127.0.0.1:8888 https://www.telerik.com

 

When clicking on the URL in the raw inspector I get 

GET http://www.telerik.com/aspnet-mvc%20HTTP/1.1 HTTP/1.1

 

going to this page http://www.telerik.com/aspnet-mvc in Chrome directly also gives the same result in the raw inspector.

 

See the screenshots attached.

 

 

hex view.png
2017-07-21_18-1...
×

Attachments Open full size

  • Guest
  • Jul 21 2017
  • Under review
Bug
  • Attach files
  • Guest commented
    December 20, 2017 04:11

    I cannot reproduce this in Windows 7 Enterprise (6.1.7601 Service Pack 1 Build 7601) using Fiddler v4.6.20173.38786 (Built: Friday, September 15, 2017). Screenshot attached.

    Fiddler Raw Ins...
    ×

    Attachments Open full size

  • Guest commented
    July 27, 2017 11:37

    also seeing this problem in windows 10

    Major  Minor  Build  Revision
    -----  -----  -----  --------
    10     0      15063  0

    really annoying, better not to use at all in raw viewer HTTP/1.1 as a fast solution

    ×

    Attachments Open full size

  • Guest commented
    July 22, 2017 10:03

    I have this problem on Windows 10 - version 10.0.15063

    ×

    Attachments Open full size

  • Eric Lawrence commented
    July 21, 2017 18:29

    This is ultimately a bug in the underlying Windows custom control, which is apparently has become over-eager and does not treat the space after the URL as a terminator for the URL itself.

    I can confirm this behavior in Windows 10 10568.962. I don't recall seeing this bug before, so it would be interesting to know what OS versions this issue reproduces on; perhaps it slipped into the Microsoft Common Controls sometime in Windows 10?

    ×

    Attachments Open full size

  • +1

Related ideas