This is a creation in Article, where the information may have evolved or changed.
This afternoon when trying to weed-fs the Collection characteristics, found a formvalue return results do not meet the expected bug, checked, only to find that because the use of the correct result. By the way, a pullrequest fix bug that contains only one line of code is submitted for this purpose r.ParseForm()
. Really "check bug thousand Days, Fix bug for a while" ...
The specific reason is simple, see the following example code to know:
Bug Replay
Package Mainimport ("Net/http") Func HelloServer1 (w http. Responsewriter, R *http. Request) {//r.parseform () Val: = R.formvalue ("key") println ("HelloServer1", Val) w.write ([]byte (val))}func He LloServer2 (w http. Responsewriter, R *http. Request) {//r.parseform () _, Fe: = R.multipartreader () if Fe! = nil {println ("HelloServer2", Fe) return} val: = R.formvalue ("key") println ("HelloServer2", Val) w.write ([]byte (val))}func HelloServer3 (w http). Responsewriter, R *http. Request) {R.parseform () _, Fe: = R.multipartreader () if Fe! = nil {println ("HelloServer3", Fe) re Turn} val: = R.formvalue ("key") println ("HelloServer3", Val) w.write ([]byte (Val))}func Main () {http. Handlefunc ("/hello1", HelloServer1) http. Handlefunc ("/hello2", HelloServer2) http. Handlefunc ("/hello3", HelloServer3) println ("Start ...") Err: = http. Listenandserve (": 8888", nil) if err! = Nil {println ("error", Err)}}
The results of the three post requests were as follows:
- Return result is correct
curl -F "name=yanyiwu" "localhost:8888/hello1?key=value1"value1
Although R.parseform was not called before calling R.formvalue, the results returned are correct. Because r.form = = nil within the R.formvalue function, Parsemultipartform is called first.
- Return result Error
curl -F "name=yanyiwu" "localhost:8888/hello2?key=value2"
The same r.parseform was not called before calling R.formvalue, but the returned result was incorrect. Because R.multipartreader was called before R.formvalue, the result of the call to R.multipartreader would result in parsemultipartform failures that were called after the R.formvalue function. The reason for the failure is to cause one http: multipart handled by MultipartReader
error, so the result does not meet the expectations. Specific reasons can look at the files inside the go source golang/go/src/net/http/request.go
.
- Return result is correct
curl -F "name=yanyiwu" "localhost:8888/hello3?key=value3"value3
Because of the addition of a line r.ParseForm()
, everything.
Solution Solutions
Remember to R.parseform before calling R.formvalue.
Go Net/http source can also be more perfect a little
In fact, I personally think, go source inside r.formvalue function inside call Parsemultipartform, did not check Parsemultipartform return value is not perfect practice. Personally, you should check the return value, although you cannot return the error (because the return value of R.formvalue is only one, string type), but you can print the error to remind the developer.
Dedicated Fork a go source, modified to submit a pull request, only to see the Golang/go GitHub Warehouse pull Request list is impressively affixed with an unacceptable pull request
form of the submission code. So forget it.