А что мешает сеошникам воспользоваться сеошными методами и прописать в
robots.txt что-то вроде Disallow: *//* ?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
20 марта 2017 г., 22:06 пользователь Gena Makhomed написал:
> On 20.03.2017 18:57, Илья Шипицин wrote:
>
> проще отключить merge и разруливать уже в приложении
>>>
> отключать merge_slashes нельзя, тогда сломается вся логика работы:
>>> http://nginx.org/ru/docs/http/ngx_http_core_module.html
On 20.03.2017 18:57, Илья Шипицин wrote:
проще отключить merge и разруливать уже в приложении
отключать merge_slashes нельзя, тогда сломается вся логика работы:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes
сломается только, если у вас используются префиксные локейш
20 марта 2017 г., 21:57 пользователь Vadim A. Misbakh-Soloviov <
ng...@mva.name> написал:
> > тема с merge_slashes redirect достаточно популярная,
> > странно что это до сих пор еще никто не реализовал в nginx.
>
> На самом деле это попахивает недопониманием некоторыми "SEO'шниками"
> реальных
> а
> тема с merge_slashes redirect достаточно популярная,
> странно что это до сих пор еще никто не реализовал в nginx.
На самом деле это попахивает недопониманием некоторыми "SEO'шниками" реальных
алгоритмов работы поисковиков (собственно, а откуда бы им их понимать, если не
они их разрабатывали).
20 марта 2017 г., 21:51 пользователь Gena Makhomed написал:
>
> On 20.03.2017 18:21, Илья Шипицин wrote:
>
> проще отключить merge и разруливать уже в приложении
>>
>
> отключать merge_slashes нельзя, тогда сломается вся логика работы:
> http://nginx.org/ru/docs/http/ngx_http_core_module.html#mer
On 20.03.2017 18:21, Илья Шипицин wrote:
проще отключить merge и разруливать уже в приложении
отключать merge_slashes нельзя, тогда сломается вся логика работы:
http://nginx.org/ru/docs/http/ngx_http_core_module.html#merge_slashes
On 20.03.2017 17:02, Pavel V. wrote:
> Локейшном с регулярко
проще отключить merge и разруливать уже в приложении
20 марта 2017 г., 19:41 пользователь Gena Makhomed написал:
> Здравствуйте!
>
> Можно ли сделать в директиве merge_slashes параметр redirect,
> чтобы из урла с несколькими слешами в канонический урл
> преобразование происходило путем 301 редир
На втором запросе — POST.
См non_idempotent директиву, чтобы отправлять post-запросы кросс-апстрим
SK
> 20 марта 2017 г., в 18:53, BieZax написал(а):
>
> Не совсем понятно. Т.е. это нормально, что при одной и той же
> ситуации с разницей в 2 секунды я получаю разное поведение?
> Y
Hello!
On Mon, Mar 20, 2017 at 11:40:57AM -0400, BieZax wrote:
[...]
> proxy_next_upstream error timeout invalid_header http_500
> http_503 http_502 http_504;
[...]
> 2 строчки из лога, идущие подряд:
> 10.105.5.152 - vasya [20/Mar/2017:17:03:15 +0300] "GET
> /abc/Account/Logi
Не совсем понятно. Т.е. это нормально, что при одной и той же
ситуации с разницей в 2 секунды я получаю разное поведение?
Yuriy Medvedev Wrote:
---
> Nginx, это пассивные проверки.
>
> 20 марта 2017 г., 18:40 пользователь BieZax
>
Nginx, это пассивные проверки.
20 марта 2017 г., 18:40 пользователь BieZax
написал:
> Добрый день.
> Имеется следующий конфиг:
>
> location = /abc/auth {
> internal;
> proxy_set_header X-CAuth-Realm "Registration";
> proxy_set_header X-C
Добрый день.
Имеется следующий конфиг:
location = /abc/auth {
internal;
proxy_set_header X-CAuth-Realm "Registration";
proxy_set_header X-CAuth-Base "access";
proxy_set_header X-CAuth-Table "users";
proxy_se
Здравствуйте.
Вы писали 20 марта 2017 г., 21:41:04:
> Можно ли сделать в директиве merge_slashes параметр redirect,
> чтобы из урла с несколькими слешами в канонический урл
> преобразование происходило путем 301 редиректа?
Локейшном с регуляркой ситуация не разыгрывается?
--
С уважением,
Pav
Здравствуйте!
Можно ли сделать в директиве merge_slashes параметр redirect,
чтобы из урла с несколькими слешами в канонический урл
преобразование происходило путем 301 редиректа?
SEO-шники пристали, говорят так как сейчас - получается дубль страниц
и чтобы дубля не было надо делать редирект вмес
Hello!
On Mon, Mar 20, 2017 at 08:35:36AM -0400, malaf wrote:
> Здравствуйте.
>
> В error.log наблюдали такие ошибки:
>
> [crit] request reference counter overflow while processing
> "next_subrequest_uri", client: , server: , request: "GET
> HTTP/1.1", subrequest: "subrequest_uri", host: "", r
Здравствуйте.
В error.log наблюдали такие ошибки:
[crit] request reference counter overflow while processing
"next_subrequest_uri", client: , server: , request: "GET
HTTP/1.1", subrequest: "subrequest_uri", host: "", referrer:
Подскажите, какое максимальное значение имеет счетчик ссылок?
Post
Исходящие запросы помечаются не нами, это мандатные метки, добавляемые ОС
AstraLinux SE, совместимости с которой мы добиваемся. Так что этот механизм
мы поменять к сожалению не можем, только на сервере каким-то образом до
nginx или в самом nginx эти метки перевести в http-заголовки или переменные
о
On Mon, Mar 20, 2017 at 04:18:59AM -0400, Archy wrote:
> Может быть есть возможность просто чтения сырых tcp-пакетов запроса?
В nginx? Конечно же нет. Вообще, tcp это абстракция потока данных
(stream), приложение tcp не видит никаких пакетов. Передавать на этот
уровень информацию по отдельным п
Спасибо, ответил вышел по поводу необходимости реализации в nginx, в
принципе можно перед ним поставить сервис, но не хотелось велосипедить,
вдруг что-то подобное уже есть в коробке.
Maxim Konovalov Wrote:
---
> On 3/17/17 8:35 PM, Archy wrote:
Метка приходит с запросом браузера с клиента, при этом на сервере приложение
на php. Между php и клиентом стоит NginX потому на него основной взгляд.
Имеет смысл какую-то прослойку на 80й порт делать, типа haproxy, а NginX
ставить неё?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,27
On 3/17/17 8:35 PM, Archy wrote:
> Здравствуйте!
>
> Стоит задача передачи в приложение меток, передаваемых с клиента в поле
> опций IPv4 пакета. Метки добавляются по RFC1108 типа
> IPOPT_SEC,5,0xAB,03,12
>
> Подскажите, куда копать, можно ли сделать на основе существующих модулей
> разбор пакета
Почему вы вообще решили это делать на NginX, а не на... Да на чём угодно, что
более узкоспецифично, чем веб-сервер :)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Может быть есть возможность просто чтения сырых tcp-пакетов запроса?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,273014,273033#msg-273033
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
24 matches
Mail list logo
