panic: slice bounds out of range #3623
Comments
|
Thanks for the great report. I was able to reproduce the bug, so finding a fix will be much easier with the information you provided. |
|
This is caused because the |
|
So this is fun: it turns out Still looking for a fix without changing the placeholder (since I think most users want the path placeholder to return the unescaped path). |
|
Okay, so the std lib has So I wrote my own, and now the tests pass (including a new one for this issue), so I hope that means it's correct: func indexFold(haystack, needle string) int {
nlen := len(needle)
for i := 0; i+nlen < len(haystack); i++ {
if strings.EqualFold(haystack[i:i+nlen], needle) {
return i
}
}
return -1
}This should fix the problem because before we were finding a position using the lower-cased version of the path, then using that same position with the original version of the path, which has a different length (😬)... this solution does not create a lowercase version of the path, but still does case-insensitive substring searching. |
|
Should be fixed now, please give it a try with the latest build artifacts! |
|
I've got zero new panic in the last 10 days of tests, fix is working as expected, thaks! |
I'm seeing in caddy logs some panics, here is a sample:
this is an extract of the relative access.log:
{ "level":"info", "ts":1594993992.0698013, "logger":"http.log.access.log2", "msg":"handled request", "request":{ "method":"GET", "uri":"/%E2%C3%83%C6%92%C3%86%E2%80%99%C3%83%E2%80%A0%C3%A2%E2%82%AC%E2%84%A2%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%AF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BD%C3%83%C6%92%C3%86%E2%80%99%C3%83%E2%80%A0%C3%A2%E2%82%AC%E2%84%A2%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%AF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BD", "proto":"HTTP/1.1", "remote_addr":"207.46.13.85:3472", "host":"www.endelwar.it", "headers":{ "Cache-Control":[ "no-cache" ], "Connection":[ "Keep-Alive" ], "Pragma":[ "no-cache" ], "Accept":[ "*/*" ], "Accept-Encoding":[ "gzip, deflate" ], "User-Agent":[ "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" ] }, "tls":{ "resumed":false, "version":771, "ciphersuite":49196, "proto":"", "proto_mutual":true, "server_name":"www.endelwar.it" } }, "common_log":"207.46.13.85 - - [17/Jul/2020:15:53:12 +0200] \"GET /%E2%C3%83%C6%92%C3%86%E2%80%99%C3%83%E2%80%A0%C3%A2%E2%82%AC%E2%84%A2%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%AF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BD%C3%83%C6%92%C3%86%E2%80%99%C3%83%E2%80%A0%C3%A2%E2%82%AC%E2%84%A2%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%AF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BF%C3%83%C6%92%C3%86%E2%80%99%C3%83%C2%A2%C3%A2%E2%80%9A%C2%AC%C3%85%C2%A1%C3%83%C6%92%C3%A2%E2%82%AC%C5%A1%C3%83%E2%80%9A%C3%82%C2%BD HTTP/1.1\" 0 0", "duration":0, "size":0, "status":0, "resp_headers":{ "Server":[ "Caddy" ] } }Other URIs that trigger the panic are these:
I've found both GET and HEAD requests, coming from bing search and a webscraper looking for specific archive files in webroot
This happens on a debian 9 with Caddy 2.1.1 with no additional modules.
Caddyfile is the following:
The text was updated successfully, but these errors were encountered: