44 pointsby mrshuan hour ago7 comments
  • basilikum27 minutes ago
    > As it turns out, bash can speak HTTP by itself.

    No, it can not. Bash lets you open TCP sockets.

    What you are doing here is trying to speak HTTP yourself, which is fine for testing and debugging, and hella cool for fun to do by hand, but you will shoot yourself in the foot if you try to use this pseudo http client unattended in reality. This toy code does not parse HTTP properly and will break.

    You could of course write a full http/1.1 client in bash, you can even do a full http server in pure bash: https://github.com/bahamas10/bash-web-server

    For less insane, non-bash shells there is always nc which is usually probably the wiser choice.

    • augusto-moura2 minutes ago
      Http is pretty lenient on parsing errors, it could work for basic stuff.

      Ol' CGI [1] used to work by piping the request as stdin to a bin and piping stdout as response, it was the binary responsability to parse and write proper HTTP (or any other protocol). You could write your binary as Perl or PHP which had HTTP libraries for parsing and responding baked in. Or, and it was not that uncommon, to wire bash scripts to CGI-bin just for fun. But yes, it was always dangerous doing it

      [1]: https://en.wikipedia.org/wiki/Common_Gateway_Interface

    • a-dub23 minutes ago
      it's not that insane. i've been manually typing http requests in since before http/1.1 and the mandatory host header.

      it is insane to use it for anything serious (also the opposite, implementing webservers in bash), but for quick testing it's pretty great!

    • morpheuskafka6 minutes ago
      > No, it can not. Bash lets you open TCP sockets.

      I thought you had to use a program called netcat for that--if not then what is the point of that binary? And for that matter, can't you also use telnet to manually send HTTP?

    • mrshu23 minutes ago
      > No, it can not. Bash lets you open TCP sockets.

      Very fair pushback -- I did get carried away and will update the article to be more precise. Thanks for raising it!

      > For less insane, non-bash shells there is always nc which is usually probably the wiser choice.

      For completeness, `nc` or any netcat equvialent I could think of was not available in the image I was trying this with. It would certainly be a better option though.

      • bearjaws9 minutes ago
        This is the most Claude pilled comment I've seen here.
  • orthogonal_cubea minute ago
    It was fun exploring this to make a native-shell-only peer-to-peer file transfer utility at work for some automation scripts. At least, it was until trying to replicate it in Powershell was somehow triggering Crowdstrike and the corporate Cybersecurity team thought I was writing malware.
  • simonw19 minutes ago
    Neat, works against example.com

      exec 3<>/dev/tcp/example.com/80
      printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' >&3
      cat <&3
    
    Outputs:

      HTTP/1.1 200 OK
      Date: Tue, 16 Jun 2026 17:37:45 GMT
      Content-Type: text/html
      ...
    
    I always end up on example.com for this kind of thing because there are so few domains these days that don't enforce https!
  • mrshuan hour ago
    I ran into this while checking connectivity between containers on an internal Docker network where the image had neither curl nor wget.

    The main surprise was that Bash has /dev/tcp which lets you do the equivalent of an HTTP request with a bit of shell magic, for instance:

      exec 3<>/dev/tcp/service/8642
      printf 'GET /health HTTP/1.1\r\nHost: service\r\nConnection: close\r\n\r\n' >&3
      cat <&3
    
    
    Where `service` is just the hostname of whatever you’re talking to and 8642 is the port you are trying to talk HTTP to.

    Pretty cool!

    • sevenzero41 minutes ago
      It seems pretty cool, but I am wondering if there's any drawback on just using images that support curl? I can't think of any and to me it's kinda a must have, even on production images
      • xmodem15 minutes ago
        More than one ~500 employee company I've worked at has had security policies either encouraging or requiring the use of "distro-less" images - images with no OS components other than the absolute minimum required to run the application. For go binaries this meant literally nothing in the container apart from the executable.

        In theory it has a couple of benefits. You don't have to re-deploy your image to patch CVE's in OS components if you don't have any OS components. And it provides some measure of defence-in-depth - one could certainly theory-craft a scenario where an attacker gains some limited control over your application and then uses some OS component to escalate.

        These days if a security engineer is proposing my team adopt distro-less containers to receive these benefits, I would point out that we need to weigh them against the very real drawbacks of not having standard debugging tools available where and when weneed them. And also to consider the relative impact of other defence-in-depth measures they could be pursuing instead - such as any sort of network policy to limit network traffic.

      • OptionOfT16 minutes ago
        I always recommend to not have any dependencies outside of the code.

        So we start at compiling the codebase (Rust) against MUSL. That way we can run it with FROM scratch images.

        If we need more tooling available at runtime, then we look at alpine, but still using MUSL.

        If MUSL itself is proving problematic, or if some of the libraries we use need glibc then we can look at using some locked down image.

        The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.

        • xmodem8 minutes ago
          > The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.

          What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?

      • mrshu27 minutes ago
        That is indeed a solid pushback! :)

        For what its worth, this container used `python:3.12.2-slim-bookworm` and I really would not expect that sort of an image to bundle `curl` -- even if it is intended for production.

        • sevenzero24 minutes ago
          Ah I see so it was basically a minimal image that bundles just python? I can see why it wouldn't bundle curl! Thought it was a custom Image for some reason, hence my original comment
          • mrshu20 minutes ago
            Yes, a very minimal image indeed. Had it been a custom image, curl would be one of the first things I would make sure it contains :)
      • figmert24 minutes ago
        This of course only supports http, not https. It's great for health checks e.g. in a docker environment. To do https, you'd have to use something like socat, but of course that doesn't use bash only.
      • 31 minutes ago
        undefined
      • giobox21 minutes ago
        It's also a two line Dockerfile to add wget or curl to almost any pre-existing container image. This is a fun idea though.
  • devsda5 minutes ago
    Yes, it used to be my goto few times when some devices tried to lockdown everything with bare minimum core utils and no network capable tools like curl etc.
  • AndrewStephens31 minutes ago
    This is pretty neat if all you need is to ping a local server but please use curl (or something equivalent) for contacting remote services. HTTP1.1 seems like such a simple protocol but in the real world you need to deal with proxies, different encodings, and redirects. Curl takes care of that (and a host of other annoying stuff) for you.
    • mrshu26 minutes ago
      Totally!

      I was really just trying to see if intra-container connectivity works, and this ended up being a very quick way of doing so. (The alternative being building and deploying a new image, which would likely take significantly longer.)

      • KomoD17 minutes ago
        > The alternative being building and deploying a new image, which would likely take significantly longer

        You said the image was Python, though? Using that is way easier and faster. https://news.ycombinator.com/item?id=48558763

        If all you need to know is that it can connect:

        python3 -c 'import socket as s;s.create_connection(("8.8.8.8",53))'

        or http:

        python3 -c 'from urllib.request import*;print(urlopen("http://example.com").status)'

  • sc68cal37 minutes ago
    That's pretty neat, thanks for sharing