Add localhost:8080 in readme

[shirshak55]

I don't know why there is local.httptoolkit.tech ( I guess it assumes our proxy is already redirected from the proxy which is usually not the case when we first install httptool-kit-ui?

However, on my end localhost:8080 was running hence the patch.

[pimterry]

This is an excellent example of Chesterton's Fence :smiley: - don't remove something unless you can explain why it's there.

That said, this could be better documented! Sorry about that.

local.httptoolkit.tech exists because Auth0 does not allow configuring localhost for various parameters in the login system, which only allows logins from recognized domain names.

The end result is that it's impossible to log into the app on localhost. It's also not currently possible to even view the pricing plans, due to CORS restrictions in the accounts API (though I think that could be changed).

If you open the app on localhost and then click 'Get Pro', then it'll crash immediately. If you open it on local.httptoolkit.tech then everything works perfectly. Does that make sense?

[shirshak55]

@pimterry the problem arises because local.httptoolkit.tech is not working.

thanks. At least I know why the decision was made to use local.httptoolkit.tech.

[pimterry]

You need to include the port too (8080) so that the full URL is local.httptoolkit.tech:8080.

local.httptoolkit.tech is just a DNS name that resolves to 127.0.0.1. On most systems that means it's exactly the same as localhost - it's just that because it's a real domain it can be used with Auth0 and similar configuration elsewhere.

That Ubuntu Apache page is coming from your own computer, and you'll probably see the same thing if you visit localhost directly without specifying a port too.

[shirshak55]

@pimterry sorry I got misguided in hurry. It's not working for me as intended.

Is it some kind of DNS related issue?

httptoolkit-ui via  v17.0.1 ➜  dig local.httptoolkit.tech    

; <<>> DiG 9.16.8-Ubuntu <<>> local.httptoolkit.tech
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35650
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;local.httptoolkit.tech.        IN  A

;; ANSWER SECTION:
local.httptoolkit.tech. 3433    IN  A   127.0.0.1

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 09 10:50:03 +0545 2021
;; MSG SIZE  rcvd: 67

httptoolkit-ui via  v17.0.1 ➜  dig local.httptoolkit.tech:8080

; <<>> DiG 9.16.8-Ubuntu <<>> local.httptoolkit.tech:8080
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65108
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;local.httptoolkit.tech:8080.   IN  A

;; Query time: 560 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 09 10:50:17 +0545 2021
;; MSG SIZE  rcvd: 56

I tried in chrome to reconfirm and it seems the issue is there

I am using cloudflare family dns

[pimterry]

I think there's some confusion here. local.httptoolkit.tech is the hostname, and 8080 is the port, separated by a colon (so :8080). When you pass those to dig, the first one is returning the result correctly (127.0.0.1), and the latter is failing because dig & DNS don't know anything about ports at all. There is no domain name called local.httptoolkit.tech:8080, because you can't have colons in domain names, which is why that fails.

The dig results there are all correct - dig localhost:8080 will fail in exactly the same way.

It is a little surprising that the page doesn't load for you. I strongly suspect that this is because the web server isn't actually running, but the service worker is active in your browser.

The service worker allows HTTP Toolkit to work totally offline, and to update the web app asynchronously, so that most of the time when a user opens HTTP Toolkit they don't have to download anything - after the first run, it all loads even without internet and you never have to wait for the web page to download.

However, service workers are only supported by browsers when you're using an HTTPS domain or one of a couple of other special domain names, including localhost.

Service workers can be confusing, because this means even if you stop your local HTTP Toolkit web server completely, localhost:8080 will keep working just fine, serving the last version of the website you had.

Does that sound plausible? You can test it by visiting the localhost page, opening the developer tools, switching to the 'Application' page, and clicking 'Deregister'. This will remove the service worker. If you then refresh, the page probably won't load any more, because the service worker is gone and the web server isn't running. This is another good reason not to use localhost, because local development with the service worker can be very confusing.

Does that all make sense? End result: I think you've forgotten to run npm start, and if you make sure the web server is running with that then local.httptoolkit.tech:8080 should load just fine.

[shirshak55]

@pimterry its not service worker for sure.

[pimterry]

The failing window there shows PROXY_CONNECTION_FAILED and a proxy error - it's having a problem connecting to its proxy, not to local.httptoolkit.tech.

[shirshak55]

@pimterry there is no proxy . I tried it from firefox too. Something is strange.

[shirshak55]

I see when I ping localhost it replies like this. Is this the culprit .

64 bytes from localhost (::1): icmp_seq=23 ttl=64 time=0.028 ms 64 bytes from localhost (::1): icmp_seq=24 ttl=64 time=0.028 ms 64 bytes from localhost (::1): icmp_seq=25 ttl=64 time=0.020 ms 64 bytes from localhost (::1): icmp_seq=26 ttl=64 time=0.022 ms

And doing this works in browser.

http://[::1]:8080/

[pimterry]

So in the browser, with the service worker deregistered every time, [::1] works but 127.0.0.1 does not? That's very odd.

Ping using IPv6 by default is unusual, but it's not a big problem, both 127.0.0.1 and ::1 are equally valid there.

The browser issue means that the server is only accessible to you via IPv6 for some reason, and it's either not listening on IPv4 (unlikely, since we're just using webpack's default settings, which definitely supports IPv4 by default). Either that or your browser is failing to use IPv4 for connections somehow.

Either way, I have no idea what's going on I'm afraid! My best guess is something is very broken with your OS networking configuration. I would restart your computer, try a different network, and try to reset your network settings generally.

It might also be useful to test with the browser out of the loop. You can try running curl local.httptoolkit.tech:8080 and curl localhost:8080 in a terminal. If the server is available correctly on each address then it will show you the basic page HTML. If it doesn't then something is wrong. Curl doesn't support service workers, so this can be a little simpler to debug.

[shirshak55]

@pimterry

Idk

httptoolkit-ui via  v17.0.1 ➜  curl -vvv local.httptoolkit.tech:8080
*   Trying 127.0.0.1:8080...
* connect to 127.0.0.1 port 8080 failed: Connection refused
* Failed to connect to local.httptoolkit.tech port 8080: Connection refused
* Closing connection 0
curl: (7) Failed to connect to local.httptoolkit.tech port 8080: Connection refused
httptoolkit-ui via  v17.0.1 ✗  

Localhost works

httptoolkit-ui via  v17.0.1 ✗  curl -vvv  localhost:8080         
*   Trying ::1:8080...
* Connected to localhost (::1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Accept-Ranges: bytes
< Content-Type: text/html; charset=UTF-8
< Content-Length: 4667
< ETag: W/"123b-0PMIdNXapdi1YGNfHgHEyx3il9g"
< Date: Tue, 09 Nov 2021 15:30:13 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <meta name="robots" content="noindex">
    <base href="/" />
    <link rel='shortcut icon' type='image/x-icon' href='https://httptoolkit.tech/favicon.ico' />
    <link rel='stylesheet' href='/fonts.css' />
    <meta name="viewport" content="width=device-width">
    <title>HTTP Toolkit</title>
    <style>
        html, body {
            height: 100%;
            overflow: hidden;

            font-family: Lato, Arial, sans-serif;
        }

        #app-loading-placeholder {
            position: absolute;
            top: 0;
            right: 0;
            bottom: 0;
            left: 0;
            display: flex;
            flex-direction: column;
            align-items: center;
            justify-content: center;
        }

        #app:not(:empty) ~ #app-loading-placeholder { display: none; }

        #initial-logo, #progress-logo {
            position: absolute;
        }

        #initial-logo {
            filter: grayscale()
        }

        #progress-logo {
            clip-path: inset(0 100% 0 0);
            transition: clip-path 0.5s;
        }

        #app-loading-error {
            margin-top: 520px;
            font-weight: bold;
            font-size: 40pt;
            text-align: center;
        }

        #app-loading-error-details {
            margin-top: 10px;
            font-size: 20pt;
        }

        #app {
            height: 100%;
        }
    </style>
  </head>
  <body>
    <div id="app"></div>
    <div id="app-loading-placeholder">
      <img id="initial-logo" src="bafe358ef4e6624aa084910b4107c302.png">
      <img id="progress-logo" src="bafe358ef4e6624aa084910b4107c302.png">
      <div id="app-loading-error"></div>
      <div id="app-loading-error-details"></div>
    </div>

    <script>
        const bgColor = localStorage.getItem('theme-background-color') || '#d8e2e6';
        document.querySelector('html').style.backgroundColor = bgColor;

        let progressElement = document.getElementById('progress-logo');
        let errorElement = document.getElementById('app-loading-error');
        let errorDetailsElement = document.getElementById('app-loading-error-details');

        let progress = 0;
        function setProgress(newProgress) {
            progress = Math.max(progress, newProgress);
            progressElement.style.clipPath = 'inset(0 ' + (100 - progress) + '% 0 0)';
        }

        setTimeout(function () {
            let appScript = document.scripts[document.scripts.length - 1];

            setTimeout(() => setProgress(10), 100);

            // Fake page loaded -> script loaded progress, since we're blind here.
            let initialProgressInterval = setInterval(function () {
                let newProgress = progress + (50 - progress) / 3;
                setProgress(newProgress);
            }, 500);

            // Triggered when script has loaded and starts running
            document.addEventListener('load:executing', function () {
                clearInterval(initialProgressInterval);
                setProgress(60);
            });

            // Triggered when sync code from script has finished
            appScript.addEventListener('load', function () {
                setProgress(75);
            });

            // Triggered when _everything_ is loaded and run
            window.addEventListener('load', function () {
                setProgress(90);
            });

            // The store & Mockttp setup is done, and React is rendering.
            document.addEventListener('load:rendering', function () {
                setProgress(100);
            });

            document.addEventListener('load:failed', function (evt) {
                setProgress(100);

                let error = evt.error || {};

                if (error.isTimeout) {
                    errorElement.innerText = 'This is taking longer than normal...';
                    errorDetailsElement.innerHTML = 'If this persists or happens often ' +
                        'please <a href="https://github.com/httptoolkit/httptoolkit/issues/new">file an issue</a> ' + 'and help make HTTP Toolkit faster.';
                } else {
                    errorElement.innerText = 'Startup failed: "' + error.message + '"';
                    errorDetailsElement.innerHTML = 'Please ' +
                        '<a href="https://github.com/httptoolkit/httptoolkit/issues/new">file an issue</a>, ' +
                        "and we'll get this fixed ASAP";
                }
            });
        }, 0);
    </script>
  <script type="text/javascript" src="app.js"></script></body>
* Connection #0 to host localhost left intact
</html>%    

Its strange to be honest lol. Localhost:80 shows default ubuntu page indicating 127.0.0.1 is working.

And there is no chance of service workers because I am running httptoolkit in private mode?

Do we have any discord, element or any server. May be we can chat :p. Its a trivial problem as there are workarounds but its weird issue lol :p

[pimterry]

Yep, so it looks like your webpack server is accessible only via IPv6, but not via IPv4. Very weird! That shouldn't happen, sounds like we need to tweak the webpack config.

What do you see if you run netstat -plnt | grep 8080? That will show what interfaces are being listening on.

[shirshak55]

httptoolkit-ui via  v17.0.1 ✗ netstat -plnt | grep 8080 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp6 0 0 ::1:8080 :::* LISTEN 8541/node

[shirshak55]

Logs also look ok.

httptoolkit-ui via  v17.0.1 ➜  npm start                 

> httptoolkit-ui@0.1.0 start
> node-dev ./node_modules/httptoolkit-server/bin/run start & npm run start:web

> httptoolkit-ui@0.1.0 start:web
> env-cmd -f ./automation/ts-node.env webpack-dev-server --config ./automation/webpack.dev.ts

(node:12901) [DEP0125] DeprecationWarning: The _stream_wrap module is deprecated.
(Use `node --trace-deprecation ...` to show where the warning was created)
Config checked in 10 ms
Certificates setup in 3 ms
Standalone server started in 6 ms
Server started in 10 ms
Total startup took 29 ms

[pimterry]

No, that deprecation warning is fine, that's nothing to do with networking.

On my machine running netstat, I see this:

tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      168702/node         

So that's the problem! Not sure how to fix it though.

Can you try out the various values from https://webpack.js.org/configuration/dev-server/#devserverhost and let me know which ones do work for you? Those options should go in here.

[shirshak55]

@pimterry

Finally got it working.

    devServer: {
        contentBase: common.output!.path!,
        host:'127.0.0.1',
        public: "local.httptoolkit.tech:8080",
        historyApiFallback: true,
    },

[pimterry]

Excellent! Looks like that should work in all cases, so I'm very happy to change the config to use that everywhere. Can you open a PR?