 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
14 messages in ru.sysoev.nginxRe: Rewriting https to http| From | Sent On | Attachments |
|---|---|---|
| iane...@public.gmane.org | Jan 11, 2007 1:26 pm | |
| Igor Sysoev | Jan 11, 2007 1:40 pm | |
| Jonathan Dance | Jan 12, 2007 3:56 am | |
| Jonathan Dance | Jan 12, 2007 4:06 am | |
| Igor Sysoev | Jan 12, 2007 4:16 am | |
| Igor Sysoev | Jan 12, 2007 4:32 am | |
| Jonathan Dance | Jan 12, 2007 4:33 am | |
| Jonathan Dance | Jan 12, 2007 4:40 am | |
| Igor Sysoev | Jan 12, 2007 4:42 am | |
| Igor Sysoev | Jan 12, 2007 4:45 am | |
| Jonathan Dance | Jan 12, 2007 5:20 am | |
| Igor Sysoev | Jan 12, 2007 5:35 am | |
| Igor Sysoev | Jan 12, 2007 6:41 am | |
| Jonathan Dance | Jan 12, 2007 6:55 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Rewriting https to http | Actions... |
|---|---|---|
| From: | Igor Sysoev (is-G...@public.gmane.org) | |
| Date: | Jan 12, 2007 6:41:26 am | |
| List: | ru.sysoev.nginx | |
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/