Rewriting https to http
is at rambler-co.ru
Fri Jan 12 16:35:32 MSK 2007
On Fri, 12 Jan 2007, Jonathan Dance wrote:
>> "abcdefgh" < "b"
> I think you mean "alphabetical," or more specifically "in language
> order" which is probably what you meant by "lexical."
Here is quote from FreeBSD strcmp(3) man:
The strcmp() and strncmp() functions lexicographically compare the null-
terminated strings s1 and s2.
> I can see how an alphabetical list might work, but not completely.
> Either way, I believe the end result is the same, which is the most
> important thing for the docs -- the longest matching string will be
> the one which is used -- but your way is more efficient.
> I think what you're doing is searching the alphabetical list for where
> you would find the request URI (even though the request URI is not
> necessarily in the list). But, then you might have to backtrack up the
> list until you find a matching path. For example, if the locations are
> as such:
> And the request is /n, then the initial search would return 1 -- e.g.,
> in order to insert /n into the list, it would go after /a.
> /a <==
> However, /a doesn't match /n so you would have to go back up the list
> until you find /, which would match.
> Maybe you found a way around this problem though. :)
I was wrong in my correction:
nginx finds the longest match to conventional string.
These strings are sorted internally in lexical order,
- so the search is terminstaed just when URI became
- lexically more than a string.
+ so the search is terminated just while URI is lexicographically
+ equal or more than string.
1) "/n" is tested again "/", it's match, nginx stores the "/" configuration.
The search continues, because "/n" >= "/".
2) then "/n" is tested again "/a", it does not match.
The search continues, because "/n" >= "/a".
3) then "/n" is tested again "/z", it does not match.
The search is stopped because "/n" < "/z".
The last stored configuration (i.e. "/" is used).
More information about the nginx