14 messages in ru.sysoev.nginxRe: Rewriting https to http
FromSent OnAttachments
iane...@public.gmane.orgJan 11, 2007 1:26 pm 
Igor SysoevJan 11, 2007 1:40 pm 
Jonathan DanceJan 12, 2007 3:56 am 
Jonathan DanceJan 12, 2007 4:06 am 
Igor SysoevJan 12, 2007 4:16 am 
Igor SysoevJan 12, 2007 4:32 am 
Jonathan DanceJan 12, 2007 4:33 am 
Jonathan DanceJan 12, 2007 4:40 am 
Igor SysoevJan 12, 2007 4:42 am 
Igor SysoevJan 12, 2007 4:45 am 
Jonathan DanceJan 12, 2007 5:20 am 
Igor SysoevJan 12, 2007 5:35 am 
Igor SysoevJan 12, 2007 6:41 am 
Jonathan DanceJan 12, 2007 6:55 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Rewriting https to httpActions...
From:Igor Sysoev (is-G@public.gmane.org)
Date:Jan 12, 2007 5:35:09 am
List:ru.sysoev.nginx

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.

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/