[phendrenad2]

It's done for speed. Straightforward text replacement is so much faster than checking to see if a path is properly terminated by a slash. And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2.

[amluto]

I find it hard to believe that searching for “..” would even show up in a benchmark.

In any case, it seems that nginx does try to search for .. but has a bug in the corner case where the “location” doesn’t end with a slash. I assume there’s some kind of URL normalization pass that happens before the routing pass, and if the route matches part of a path component, nothing catches the ..

If I’m right, this is just an IMO rather embarrassing bug and should he fixed.

[D13Fd]

Yeah, this whole thing reads to me like a bug in nginx. There is no obvious reason users would need that functionality.

[m3affan]

What are the alternarives though?

[seanw444]

To Nginx? HAProxy. Or Caddy if you're just doing web stuff.

[terom]

HAProxy does not serve static files, so it's a poor alternative for this specific case.

[okeuro49]

Your comment makes nginx sound like some fly-by-night server that only achieved its performance by making lots of tiny-yet-dangerous "optimisations" like this one.

More likely it is an omission, which could be rectified with a warning or failure running nginx -t (verify configuration).

The actual performance comes from an architectural choice between event vs process based servers, as detailed in the C10k problem article. [1]

[1] http://www.kegel.com/c10k.html

[phendrenad2]

False, the actual performance comes from architectural differences and optimizations.

[sofixa]

> And remember that Nginx became popular due to benchmarks that showed that it was more "web scale" than Apache2.

More like because it was much faster out of the box, and came with many batteries included while Apache2 required mods to be separately install.

[robertlagrant]

And the config was nicer to read and write.

[hedora]

They could simply normalize the paths when parsing the configuration file. The overhead wouldn’t show up in benchmark because it only happens once at startup (and maybe when the conf file changes)