Re: httpd: mess with PATH_INFO (again)
On Thu, Jan 18, 2018 at 10:18:29AM +, Stuart Henderson wrote: > I think it should skip redirecting for "". You can't actually issue an > HTTP request for http://example.com (without the trailing slash). > > 'A PATH_INFO of "/" represents a single void path segment.' > > I think that is "http://example.com//;. afaict httpd is doing the > right thing here. > Welp, the maintainer obviously disagrees[1]. From the looks of it, both values, "" or "/", are considered valid by standards. Could we get this or something similar in, so Flask works with httpd? It's still the second biggest Python web framework. [1]: https://github.com/pallets/werkzeug/issues/1240
Re: httpd: mess with PATH_INFO (again)
The WSGI PEP states the following: > PATH_INFO > The remainder of the request URL's "path", designating the virtual > "location" of the request's target within the application. This may be > an empty string, if the request URL targets the application root and > does not have a trailing slash. Seems that both values are valid (at least within the CGI portion that WSGI uses). Ugh, well Werkzeug probably shouldn't redirect, either. I'll see if I can push the PR [2]. [1]: https://www.python.org/dev/peps/pep-/#environ-variables [2]: https://github.com/pallets/werkzeug/issues/1240
Re: httpd: mess with PATH_INFO (again)
On Fri, Jan 19, 2018 at 08:29:13AM +0100, Ve Telko wrote: > Hi, > > problem is in your framework, server handles this correctly. > > Using PHP, PATH_INFO and > REQUEST_URI is always "/" > > for URLs like > http://foo.bar > http://foo.bar/ > http://foo.bar// > > Ve. > It's not over here, and I logged it from httpd, so it's already empty on httpd's side.
Re: httpd: mess with PATH_INFO (again)
On Thu, Jan 18, 2018 at 10:18:29AM +, Stuart Henderson wrote: > I think it should skip redirecting for "". You can't actually issue an > HTTP request for http://example.com (without the trailing slash). > True, but shouldn't a "GET /" have PATH_INFO set to "/", just like "GET /foo" results in PATH_INFO set to "/foo"? Other servers seem to handle this the same way. In the end, it appears to be a question of semantics, but since other servers don't have this problem, I'd go with simply setting it to "/" for root requests.
httpd: mess with PATH_INFO (again)
Hello,
I am running Flask apps with uWSGI as a middleware, communicating with
httpd via FastCGI sockets.
Ever since OpenBSD 6.1 I started running into problems with all of my
Flask apps. They would get caught in a redirect loop for root paths
(see [1]).
I did some debugging, and it seems that Flasks routing engine Werkzeug
has an option called `strict_slashes`[2], which will append a slash
and redirect to directory requests without a trailing slash.
When the root URL of an app is requested, e.g. "http://foo.bar;,
PATH_INFO will be set to an empty string. This causes Werkzeug to
respond with a redirect, but the next request will still come in with
PATH_INFO as "", resulting in a redirect loop.
Attached diff causes PATH_INFO to be "/" in such a case, effectively
fixing the problem for me. However, I am not well versed with the
httpd code-base. Maybe it should be corrected with a different
approach. Just sending this in to get the ball rolling.
The CGI RFC[3] states that "/" and "" are valid paths. I would assume
that for applications mounted at root, PATH_INFO should be "/" instead
of "" when requesting the index.
[1]: https://github.com/reyk/httpd/issues/71
[2]: http://werkzeug.pocoo.org/docs/0.14/routing/#werkzeug.routing.Rule
[3]: https://tools.ietf.org/html/rfc3875#section-4.1.5
Index: httpd.c
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.c,v
retrieving revision 1.67
diff -u -p -r1.67 httpd.c
--- httpd.c 28 May 2017 10:37:26 - 1.67
+++ httpd.c 18 Jan 2018 07:20:58 -
@@ -722,8 +722,12 @@ path_info(char *path)
*p = ch;
/* Break if the initial path component was found */
- if (ret == 0)
+ if (ret == 0) {
+ /* ensure leading / if path component is a directory */
+ if (S_ISDIR(st.st_mode))
+ return (p - start - 1);
break;
+ }
}
return (p - start);
Re: Scheduler hack for multi-threaded processes
Hey, On Mon, Mar 28, 2016 at 02:00:13PM +0200, Alexandre Ratchov wrote: > do you mean that sound stuttes if the diff is applied but doesn't > stutter without the diff? Stuttering may have been an exaggeration. It's more of a short, bassy click than a stutter, really. Could be that it already did this before and I just hadn't noticed. I'll observe it more closely and report back, should I have something more accurate.
Re: multi-pool malloc wip diff
Just a subjective opinion (if that counts as feedback): This in combination with the scheduler patch by mpi@ seems to greatly improve the browsing experience with Chrome, esp. when opening/closing tabs, which I suppose involves a lot of memory management calls? Other than that I haven't noticed any regressions, yet.
Re: Scheduler hack for multi-threaded processes
Can confirm all the reports regarding desktop apps becoming more responsive. I do, however, experience sound stutters, e.g. when playing music in the browser (Google Play Music) or movies with mpv. Interestingly, this does not seem to happen when playing YouTube videos.
Re: New scheduler for OpenBSD
Hey, On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote: > Chrome still isn't smooth. > > Please test, and let me know if the performance of something else > degrades. While Chrome may not be 100% smooth yet, the system is a lot more interactive. I can now play YouTube videos without stutters while doing other things. So for me it's a major improvement, thanks!
Re: touchpad slight regression (snap: 20141121-20150217)
Sorry, I must have missed this mail. This patch also seems to work with a snapshot kernel I downloaded a few minutes ago.
