2011-12-08 25 views
17

Tôi đang cố gắng tối ưu hóa chỉ thị 'vị trí' của mình và không thể tìm thấy một cách hay để xác định xem có phù hợp với vị trí cụ thể hay không. Sử dụng echo bên trong khối vị trí không được trợ giúp tại đây.Làm thế nào để kiểm soát trật tự khớp lệnh NGINX 'Vị trí'?

The NGINX ngx_http_core_module documentation có phần khó hiểu.

Để sử dụng biểu thức thông thường, bạn phải sử dụng một tiền tố:

  1. ~ Đối với trường hợp nhạy cảm phù hợp với

  2. ~* Đối với trường hợp không nhạy cảm phù hợp với

Làm thế nào trận đấu được thực hiện:

  1. Chỉ thị có tiền tố = khớp chính xác với truy vấn. Nếu tìm thấy, tìm kiếm dừng lại.

  2. Tất cả các chỉ thị còn lại với chuỗi thông thường. Nếu trận đấu này sử dụng tiền tố ^~, tìm kiếm sẽ dừng.

  3. Cụm từ thông dụng, theo thứ tự chúng được xác định trong tệp cấu hình.

  4. Nếu # 3 mang lại kết quả phù hợp, kết quả đó sẽ được sử dụng. Nếu không, trận đấu từ # 2 được sử dụng.

Số 2 ở đây cho biết "chuỗi thông thường" nhưng sau đó cho biết nó có thể được sử dụng với tiền tố ^~. Không ~ ngụ ý một RegExp? Nếu không, làm thế nào để nó xác định những gì không phải là một RegExp?

Cụ thể, tôi muốn những điều sau:

  1. Phục vụ bất cứ điều gì ra khỏi nghĩa đen /assets trực tiếp. DỪNG TÌM KIẾM.

  2. Phục vụ mọi thứ khớp với RegExp \.php$|/$ qua TÌM KIẾM TẮT nhanh CGI.

  3. Phục vụ mọi thứ khác trực tiếp qua đen /

Bằng cách này, chỉ có một nỗ lực / trận đấu cho các tập tin không động phục vụ từ bên ngoài của tài sản.

tôi có:

location ^~ /assets {}  # search-terminating literal? or regex? 
location ~ \.php$|/$ {} 
location/{}    # is this match always attempted? 

Từ các tài liệu, có vẻ như thứ tự thực tế sẽ là 1-3-2, luôn luôn chạy theo nghĩa đen / trận đấu. Có, tối ưu hóa này sẽ không tạo ra bất kỳ sự khác biệt nào về hiệu suất thực sự, nhưng tôi chỉ muốn làm sáng tỏ một số sự mơ hồ.

Trả lời

7

Từ wiki:

location =/{ 
    # matches the query/only. 
    [ configuration A ] 
} 
location/{ 
    # matches any query, since all queries begin with /, but regular 
    # expressions and any longer conventional blocks will be 
    # matched first. 
    [ configuration B ] 
} 

Vì vậy, điều này sẽ được xuất hiện đầu tiên: location ~ \.php$ {}

Mặc dù tài sản được phục vụ ra khỏi location/{}

Bên trong khối php bạn cũng muốn đảm bảo chống lại video tải lên độc hại trước khi chuyển đến fastcgi:

if ($uri ~* "^/uploads/") { 
    return 404; 
} 

Như bạn có thể thấy nginx hoạt động hơi khác một chút so với bạn có thể mong đợi.

+0

Tôi vẫn chưa rõ lý do tại sao regex sẽ được đối sánh trước tiên. được cấp không có chỉ thị "=". tiếp theo là "Tất cả các chỉ thị còn lại với các chuỗi thông thường". '/' là một chuỗi thông thường và phải khớp với bất kỳ regex nào. toàn bộ chuỗi-then-regex là một tay nắm giữ tối ưu hóa ngầm nginx dường như làm ở đây mà làm cho nó không thể khó khăn để xác định thứ tự đúng của đánh giá. tôi nghĩ rằng apache/iptables vv làm cho nó đúng bằng cách xử lý dự đoán theo thứ tự được định nghĩa như là một if if else-if/else block. mà không có bất kỳ quy tắc cụ thể "ít hơn" nào tiềm ẩn. – leeoniya

+0

Phải, điều này chắc chắn là một chút bối rối về nginx, đặc biệt là nginx của 'if' mà nên được sử dụng chỉ để viết lại/trả lại. Tôi nghĩ rằng họ đang làm việc để đơn giản hóa điều này. Đối với tình hình của bạn nó sẽ làm việc như thế này: 1. php regex kiểm tra với một điểm dừng nếu đó là một trận đấu 2./cho bất kỳ nội dung tĩnh. – m33lky

+0

bạn không chính xác về đơn đặt hàng. toàn bộ các điểm có quy tắc/tài sản như là một chuỗi đầu tiên là để tránh các chi phí của chạy regex php trên mọi yêu cầu. trên thực tế, tôi MUỐN phục vụ bất cứ thứ gì như tài sản/tài liệu/example.php mà không truyền qua FCGI. Tôi hiện đang chạy thiết lập này và regex không bắt cho example.php. nó được đặt hàng là^~/asset, /, ~ \ .php $ |/$ – leeoniya

Các vấn đề liên quan