On Tue, Oct 11, 2016 at 10:08 PM, Tim Heckman <t...@heckman.io> wrote:
> Hi Gophers! > > I ended up implementing a package for parsing the header. It didn't seem > like there was anything else purpose-built for it: > > * https://github.com/theckman/httpforwarded > The Gorilla Framework has middleware for handling this header: http://www.gorillatoolkit.org/pkg/handlers#ProxyHeaders I wonder if it can be switched to use your library? I like the idea of reusing common functionality like this. > > Any feedback on the code, or the project in general, is welcome. > > Cheers! > -Tim > > On Saturday, October 8, 2016 at 12:17:27 PM UTC-7, Tim Heckman wrote: >> >> Hey Gophers! >> >> I'm working on a small project where I'm looking to support the >> "Forwarded" header as defined in RFC-7239[1]. For those unfamiliar, it's a >> standardization and unification of the "X-Forwarded-For" and >> "X-Forwarded-Proto" headers, among others. The simplest version of the >> header looks like the following: >> >> Forwarded: for=192.0.2.1; by=192.0.2.2; proto=http >> >> My initial (naïve) thought was that I could use the >> mime.ParseMediaType()[2] function to parse the value of the header. This >> results in an error because that function is only designed to parse things >> like the "Content-Disposition" header (i.e., things that have a media-type >> before the key=value parameters). >> >> Reading RFC-7239 further, it becomes quite apparent that more complex >> header values are possible. You can not only have multiple Forwarded >> headers, but you can also have multiples of the key=value parameters within >> a single header-value. This means even the parameter parsing code of the >> mime.ParseMediaType() function isn't compatible if the request has the >> following (notice the comma in line 2): >> >> Forwarded: for=192.0.2.42; proto=http >> Forwarded: for=192.0.2.1, for=64.72.88.33 >> >> At the time of writing, RFC-7239 is in the Proposed Standard status >> (meaning it's ripe for implementation support). I've been doing some >> digging, and it doesn't seem like the stdlib of Go is capable of parsing >> this header in a meaningful way. Likewise, it doesn't look like anyone has >> tackled parsing this header as a third-party package. >> >> I wouldn't want to duplicate effort, so does anyone know if someone has >> built a package for parsing this header? >> Do you think it's a good idea to open an issue on the Go project to >> inquire about implementing a parser, in the "mime" package, that's capable >> of extracting the parameters from all "Forwarded" header values of a >> request? Is this a better fit for a third-party package? >> >> Cheers! >> -Tim >> >> [1] https://tools.ietf.org/html/rfc7239 >> [2] https://golang.org/pkg/mime/#ParseMediaType >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>, Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>, Facebook <https://facebook.com/jawnsy> *“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* — Samuel Beckett, Worstward Ho (1983) “In an adaptive environment, winning comes from adapting to change by continuously experimenting and identifying new options more quickly and economically than others. The classical strategist's mantra of sustainable competitive advantage becomes one of serial temporary advantage.” — Navigating the Dozens of Different Strategy Options <https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options> (HBR) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
