1. 51
  1.  

  2. 12

    I can’t really get behind just ignoring headers because some engineer feels like they aren’t useful anymore.

    1. 8

      He doesn’t just “feel like”, he has a justified technical position, and I don’t see any counter arguments to any of his points.

      1. 5
        • Via is actually useful, if properly used, and can detect request loops outside your network
        • Expires is actually useful if you need to expire a response at a specific date, Cache-Control doesn’t do that, it’s only use isn’t “expire my content and don’t cache”
        • X-Frame-Options is needed to support older browser, IE only supports a minimal version of CSP since 10, if you support older clients, XFO is a good security addition as CSP may not be available
        1. 5

          The repeated use of “deprecation” without obvious links to the RFCs superceding those deprecations doesn’t help. Further, the entire point of the article is pretty clearly to help advertise Fastly (which presumably wants to go after some of Cloudflare’s market).

          Like, it’s an interesting read, but I’m a bit concerned about people putting their services behind providers that sanctimoniously decide to break with RFCs because it might get them more business.

        2. 3

          From the bit at the end it doesn’t sound like they’re doing anything to the headers by default? These are headers they recommend stripping out, and there’s an example at the end of how to strip out individual headers if you want to, but a site owner would have to actually do that to have any effect.

          1. 1

            Yeah, I don’t really see the problem here.

            Nobody’s forced to look at headers they’re not interested in, and the extras don’t hurt anything, except for using a bit of bandwidth.

          2. 7

            This is a nice summary, thanks for sharing it. Combined with this tweet: https://twitter.com/kellabyte/status/996429414970703872

            …I’m inclined to wonder how much time/bandwidth would be saved at larger sites if people cleaned these up, although I suspect that “size of HTTP headers” is not the worst bottleneck for most people.

            1. 7

              For most sites the comparison goes something like javascript > unoptimized images > cookie size > other http headers for bytes/load time wasted.

              1. 6

                I suspect the impact is minimal. It’s a few hundred bytes at worst, and the site is probably more affected by 3rd party adtech or unoptimized pictures.

                1. 7

                  Somewhat related, but even small changes to the request/response can have large impact on the bandwidth consumed.

                  From Stathat “This change should remove about 17 terabytes of useless data from the internet pipes each month” https://blog.stathat.com/2017/05/05/bandwidth.html

                  1. 5

                    Optimized Images alone would most likely save a lot more since they can save a lot more too. A recent google blog loaded a 8MB GIF image to show a few second long animation in a 250x250 thumbnail. 2 minutes in ffmpeg reduced that to about 800KB.

                    Imagine if people did this on sites with more traffic than some random google product announcement blog…

              2. 4

                We need some form of “strict” mode which turns these all onto sane settings by default.

                1. 2

                  XKCD #927 😜

                  1. 4

                    I don’t think this is really relevant - it wouldn’t be a competing standard, or a standard at all really, just a baseline to start from that could vary from server to server.

                2. 1

                  This has been posted on May 10, why is it tagged historical?

                  1. 1

                    I think they’re referring to the fact some of the headers listed have historical explanations for their development/use/misuse