Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http.CanonicalHeaderKey isn't correct #823

Closed
gopherbot opened this issue Jun 1, 2010 · 6 comments
Closed

http.CanonicalHeaderKey isn't correct #823

gopherbot opened this issue Jun 1, 2010 · 6 comments

Comments

@gopherbot
Copy link
Contributor

by lukenine45:

According to the http spec
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19), the
header "ETag" ought to be emitted as "ETag" and not
"Etag", which is
currently what CanonicalHeaderKey forces it to be. It's trivial to fix;
below is one way of doing so.


diff -r baf75e1c5625 src/pkg/http/request.go
--- a/src/pkg/http/request.go   Fri May 21 20:25:08 2010 -0700
+++ b/src/pkg/http/request.go   Mon May 31 19:43:35 2010 -0500
@@ -391,6 +391,9 @@
        }
    }
    t := string(a)
+   if t == "Etag" {
+       t = "ETag"
+   }
    cmap[s] = t
    return t
 }
@peterGo
Copy link
Contributor

peterGo commented Jun 1, 2010

Comment 1:

If the ETag response-header field is an exception to the canonical header rule, are
the Content-MD5 entity-header field, the TE request-header field, and the
WWW-Authenticate response-header field also exceptions to the rule?

@gopherbot
Copy link
Contributor Author

Comment 2 by lukenine45:

Having just looked them up in that document, the answer appears to be yes.

@gopherbot
Copy link
Contributor Author

Comment 3 by lukenine45:

Although, perhaps I filed this too soon. It appears that other websites do indeed
emit "Etag".

@hoisie
Copy link
Contributor

hoisie commented Jun 1, 2010

Comment 4:

I think the best solution is to not call CanonicalHeaderKey in conn.SetHeader or 
response.addHeader. There could be many headers that are sensitive to this issue, so 
special casing a few of the above doesn't really address the problem.

@rsc
Copy link
Contributor

rsc commented Jun 3, 2010

Comment 5:

CanonicalHeaderKey is definitely correct.
The server could emit everything lower case if it wanted to
(and maybe it should, just to make the point).  Clients or servers
that insist on a particular case are in violation of the RFC.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
    Field names are case-insensitive.

Status changed to WorkingAsIntended.

@gopherbot
Copy link
Contributor Author

Comment 6 by lukenine45:

Sorry for the noise; I thought that changing this had fixed a caching problem I was
having with safari, but it turned out I goofed when testing. (I've since found the
source of my problem and it was not in the http library.)

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants