Unable to fix bad http:/// URLs using rewrite

[term srv]

I have software that connects to the Fiddler proxy and if it wants a URL like http://foo/bar it does a CONNECT to foo and then requests http:///bar. As far as I know that is not allowed. I cannot find a way that works to tell Fiddler to pass it on or rewrite the URL, instead it shows as aborted during reading request.

Reproduce case: For example a webserver at localhost:8000 and a Fiddler proxy at localhost:8888 and socat client.

socat TCP-CONNECT:localhost:8888,crlf -

send this data, including the blank line:

CONNECT localhost:8000 HTTP/1.0
Host: localhost:8000
User-Agent: foo

Fiddler response, including the blank line:

HTTP/1.0 200 Connection Established
FiddlerGateway: Direct
StartTime: 15:33:34.682
Connection: close

send this data, including the blank line:

GET http:///test HTTP/1.0
Accept-Language: en-us
Accept-Charset: iso-8859-1,*,utf-8
User-Agent: foo

Fiddler then disconnects and session properties say X-ABORTED-WHEN: ReadingRequest. Putting a rewrite in OnBeforeRequest makes no difference:

        if (oSession.fullUrl == "http:///test") {
            FiddlerObject.alert(oSession.fullUrl);
            oSession.fullUrl = "http://localhost:8000/test2";
        }

Windows 7 x64
Telerik Fiddler Web Debugger (v4.6.2.32002)

[Eric Lawrence]

To be clear, in the scenario in question, do you see the alert dialog box pop up?

[term srv]

No, I don't see any type of alert

[Eric Lawrence]

Lack of an alert suggests that your rule isn't matching. If you remove the if condition so you get an alert on every request, do you see one for the request in question?

[term srv]

It appears OnBeforeRequest isn't being called with that URL. If I put an alert on each time the function is called I never get an alert with that URL.

[Eric Lawrence]

Ah. So I think the issue here is that Fiddler is seeing that the content inside the CONNECT'd tunnel isn't a HTTPS Client Hello, so it thinks it's probably going to be a WebSocket Upgrade GET request. Because the request isn't well-formed, it bails out early before there's any chance of fixup.

Unfortunately, I can't fix issues like this anymore; you might file a feature request at https://fiddler.ideas.aha.io... assuming you can't fix the client software to generate a proper request line.

[term srv]

I can do something like this and it works fine:

GET http://localhost:8000/test HTTP/1.0
Host: localhost:8000

Accept-Language: en-us
Accept-Charset: iso-8859-1,*,utf-8
User-Agent: foo

That isn't a client hello and it works ok. Is that expected, so in other words is Fiddler's parsing of CONNECT meant to work with regular HTTP requests that are well-formed?

[Eric Lawrence]

Right, so the idea is that the code says something vaguely like:

   ReadFromSocket()

   if (LooksLikeClientHello()) return doHTTPSHandshake()

   if (LooksLikeHTTPRequest()) return doWebSocket(parseHTTPRequestFromSocket())

Where the part in yellow blows up.

[term srv]

Thanks again Eric. I have done as you suggested and filed at https://fiddler.ideas.aha.io/ideas/FID-I-124

(Also, a slight correction to my last post: Although it may be obvious there is no extra line break after the Host header line; Google's forum code block messed up the formatting when I pasted it in.)