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
Bug in H2O.next.call(env) #2234
Comments
As the error message suggested using
With this configuration opening But adding one more path segment, e.g. an additional
Is there really such a low limit on the number of allowed path segments??? This must be a bug. Possibly the same as the one for |
Since both, On my test server this works. I will likely deploy it in production, soon. Maybe it helps someone else running into the same problems with above mentioned methods:
|
Not quite working, yet: Example: Is there a way to force it to use just And all this, just because I wanted to add another |
@utrenkner Sorry for being late. I hope #2254 will fix the issue. With that PR |
I tried the same mruby handler but couldn't reproduce it. I mean, I spawned minimal upstream server ( |
@i110 Great many thanks! I will try out your patch, tomorrow. And also thank you for testing the above mruby handler. Indeed, I completely forgot about changing the underscore into a hyphen. With that change, it does work as intended and |
I refile this issue as a "bug" report, because now I tested it also under Fedora with the latest sources.
For demonstration of this bug, you can use this h2o.conf:
This works: I can access files under dir1, dir2 and dir3. And when I request
http://<my-ip-address-here>:8080/dir0
I get the Google homepage (just for demo).But adding even one more
/path
segment breaks H20.next.call(env) as described here for HardenedBSD, FreeBSD.Broken h2o.conf:
I now get an Internal Server Error. And the error log on Fedora says:
This is on a fresh Fedora 31, with H2O built from source at b9989220bea9bda30f69083b66166c4c657bdf84.
The text was updated successfully, but these errors were encountered: