<p>Are there any long-standing issues you are longing to be fixed? Now that GitHub has implemented a voting system ("reactions"), let's vote for these issues!</p>
<p>Mine favorite ones are</p>
<ol>
<li><a href="https://github.com/golang/go/issues/4800">issue 4800</a> (net/http: copy headers when following redirects) and</li>
<li><a href="https://github.com/golang/go/issues/5690">issue 5690</a> (regexp: no way to replace submatches with a function)</li>
</ol>
<hr/>**评论：**<br/><br/>Floooof: <pre><p><a href="https://github.com/golang/go/issues/4341">Issue 4341</a> (image/jpeg: correct EXIF orientation). Supporting jpeg without supporting orientation isn't really supporting jpeg. You can't do anything with an image if you don't even know which way is up.</p></pre>Floooof: <pre><p>The time package includes formats such as RFC3339, but using that format won't parse all allowed RFC3339 dates. 2006-01-02 15:04:05 Etc/GMT is therefore the specific format I have to use.</p></pre>Yojihito: <pre><p>Hardcoded weird shit date format (not even ISO standard ...) with the standard logging.</p></pre>FantomLancer: <pre><p>logger: 2009/11/10 23:00:00 main.go:12: Hello, log file!</p>
<p>Not the worst I have seen...</p></pre>FantomLancer: <pre><p>On second thought, if "11" represent the day, I agree it is pretty bad!</p></pre>Yojihito: <pre><p>Date format is PURE SHIT. ISO standard or Go developers can fuck themselfs.</p></pre>sh41: <pre><p>My current "favorite" obscure bug in <code>godoc</code> binary: <a href="https://github.com/golang/go/issues/16183" rel="nofollow">https://github.com/golang/go/issues/16183</a></p>
<p>It treats a relative import path parameter as if it were absolute if its value happens to match a <code>cmd/...</code> import path.</p></pre>sethammons: <pre><p>My favorite:
<code>
resp, err := http.Get(urlStr)
</code>
If there are too many redirects, you can get a resp AND an err, which means typical error handling leads to not closing the resp.Body. </p>
<p>[edit: link - <a href="https://github.com/golang/go/issues/3795" rel="nofollow">https://github.com/golang/go/issues/3795</a>]</p></pre>Yojihito: <pre><p>But this is fixed for 4 1/2 years now?</p></pre>sethammons: <pre><p>Not fixed actually. Brad fixed it, but then people complained about apparently valid reasons why they would need the information from the response and error and how he was breaking backwards compatibility with the fix. So the fix was removed. Now we have this obscure edge case. As long as you don't have a bunch of redirects, you are fine.
[edit: link to it in-code <a href="https://github.com/golang/go/blob/master/src/net/http/client.go#L515" rel="nofollow">https://github.com/golang/go/blob/master/src/net/http/client.go#L515</a>]</p></pre>wjkohnen: <pre><p>As far as I understand the code and its comments, the response body will have been closed before returning the response and error.</p></pre>sethammons: <pre><p>ah, I believe you are correct. Thanks.</p></pre>Yojihito: <pre><p>So ... if a webpage has more than the hardcoded 10 redirects, the defer doesn't run and I have a memory leak?</p></pre>sethammons: <pre><p>Could be leaky, yeah. Most code will exit early on the err != nil, and not drain the resp.Body nor close it. However, now as one of the enlightened, if you know you could be facing redirects, you now know you have some more special handling to do. </p></pre>Yojihito: <pre><p>That could explain why my webcrawler goes OOM. How could this "special handling" look like?</p>
<p>Example code from my webcrawler</p>
<pre><code>url := "http://www.example.de/
req, err := http.NewRequest("GET", url, nil)
if err != nil {
Error.Printf("REQ Error: %s\n", err)
return
}
req.Header.Set("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1")
// SEND HTTP REQUEST
var resp *http.Response = nil
maxRetries := 4
for i := 0; i <= maxRetries; i++ {
Debug.Printf("start HTTP Request with: %s\n", url)
resp, err = client.Do(req)
if err != nil {
if i == maxRetries {
Warning.Printf("RESP Error: %s\n", err)
return
} else {
time.Sleep(time.Duration(i+1)*time.Second + 1)
Debug.Printf("sleep for %d seconds @ %s \n", i+1, url)
continue
}
} else {
break
}
}
defer resp.Body.Close()
</code></pre></pre>sethammons: <pre><p>@wjkohnen pointed out that the code shows the resp.Body being closed prior to that error being returned; I could be mistaken about the bug.</p></pre>tdewolff: <pre><p>Mine is <a href="https://github.com/golang/go/issues/4735" rel="nofollow">https://github.com/golang/go/issues/4735</a>, inline more intelligently. Keeping debug trace is what is standing in the way. This would speedup my library by about 10-20%</p></pre>dgryski: <pre><p><code>rand.Int63</code></p></pre>gohacker: <pre><p>What about it?</p></pre>dgryski: <pre><p>Instead of a 64-bit random number, you only get 63 bits of randomness. </p></pre>gohacker: <pre><p>It seems there is some progress: <a href="https://github.com/golang/go/issues/4254" rel="nofollow">https://github.com/golang/go/issues/4254</a></p></pre>
