doc/articles/wiki: "Writing Web Applications" example writes the reponse header twice #27789
Comments
|
This is a valid issue, good catch! Thank you for the well-written report and good analysis. We should discuss how to resolve it. As you said, one option is to render the template to a There are other ways to fix this too, and it's important to come up with a solution that makes the most sense in the context of the "Writing Web Applications" tutorial and what the reader is expected to know or be exposed to by then. /cc @adg as the original author of the article, I believe. |
dmitshur
changed the title
dmitshur
added
Documentation
NeedsDecision
|
The only problem with the bytes buffer rendering is that, if the tutorial is going to cover proper error handling, we still run into the same problem down the line. My suggestion for the tutorial would probably just be to keep writing directly to the Dunno if there's a simpler solution that I'm missing though. |
This is what I came here to say. Template rendering errors are for the application author anyway, not the user, and should typically only happen during development of the program. Logging it here would be ideal, and a couple of sentences explaining this would actually improve the tutorial. |
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from `template.Execute`. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from template.Execute. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from template.Execute. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
|
Change https://golang.org/cl/136757 mentions this issue: |
|
I'm aware this still has the "Needs Decision" tag associated with it, but since all were in agreement so far, I went ahead and wrote something up to fix it. I'm not the best writer, but it's a decent start at least. |
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from template.Execute. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from template.Execute. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
dmitshur
added
NeedsFix
In the "Writing Web Applications" example, we attempt to write the response header twice when handling errors from template.Execute. Since this doesn't work in practice, it shouldn't be done in the tutorial. Instead, simply log the error, and note the reason. Fixes golang#27789
What version of Go are you using (
go version)?go1.11
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?What did you do?
Follow the "Writing Web Applications" tutorial here, up through the error handling section here: https://golang.org/doc/articles/wiki/#tmp_9. L
Look at the function
renderTemplate, reproduced here:Modify the
Pagedata structure by removing a field (or modify the template to reference a nonexisting field) so that the line:err = t.Execute(w, p)will cause an error to be created. Observe the response code sent by the application. The following line:http.Error(w, err.Error(), http.StatusInternalServerError)would imply the response code to be 500, however, the application returns 200.This is because
t.Executeis callingw.Writewhich, becausew.WriteHeaderhas not yet been called, causes an implicit call tow.WriteHeader(200). Further calls tow.WriteHeader, such as the one insidehttp.Errorare ignored.There is no way to able to send a 500 error code in the case of all errors, since
w.Writeitself can return an error, and at some point, one has to simply log an error and return without setting an error code. Optionally, the example could render to abytes.Bufferso that template rendering errors could be caught.What did you expect to see?
Based on the code, a 500 error code
What did you see instead?
Error code 200.
The text was updated successfully, but these errors were encountered: