CC @bradfitz

I think the code is fine as-is.

We're not interpreting the Location string the user sends. We're just wrapping it in HTML, which is working as designed.

I think the backslash issue you're seeing is because your shell is interpreting \ as a single , which then works its way through the functions and the HTML correctly.

I guess I just don't see the problem here.

The issue is that html encoding is being used where url encoding is supposed to be.
For example the way the link is output for a directory list is correct
https://github.com/golang/go/blob/master/src/net/http/fs.go#L93
using url encoding for the path and html encoding for the link text

Most modern browsers can cope with an incorrectly escaped " so it doesn't cause an issue from that respect, but for consistency of expected behaviour URL encoding seems like the right thing to do

Why are we still talking about an "incorrectly escaped ""? A backslash is not an escape character in HTML.

It's okay to write <a href="&lt;"> to link to <. Browsers will send %3C.

func main() {
    log.Fatal(http.ListenAndServe(":8080", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if r.URL.Path == "/" {
            http.Redirect(w, r, "/<", http.StatusFound)
            return
        }
        fmt.Fprintf(w, "Got a %#v\n\n%#v", r, r.URL)
    })))
}

I don't want to add more URL parsing in this code. That will only open the door to new bugs. The escaping is fine as-is. It's HTML-escaped in an HTML attribute. It doesn't need to be URL escaped. The fs.go code is URL escaping for historical reasons (I think HTML escaping would've been fine there too), but I'm not inclined to change it at this point.

Unless you can find an example that actually produces invalid HTML or invalid HTTP and is thus a security problem of some sort, I'm not inclined to change anything.