Rewriting https to http

[Igor Sysoev]

On Fri, 12 Jan 2007, Igor Sysoev wrote:

> 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:
>
> DESCRIPTION
>     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:
>> 
>> /
>> /a
>> /z
>> 
>> 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 <==
>> /z
>> 
>> 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.

Sorry, I was wrong again.

+   so the search continues while URI is lexicographically
+   equal or more than string.

or (more preferable variant):

+   so the search is terminated just when a string will become
+   lexicographically more than URI.

> So:
>
> 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).


Igor Sysoev
http://sysoev.ru/en/