NGINX 301 и 302 служащих маленьких nginx тела документа. Какой-либо способ удалить это поведение?

Это пытается найти закрытые ключи на Вашем компьютере; удаленный компьютер имел бы открытый ключ. Удаленные компьютеры никогда не должны иметь Вашего закрытого ключа (если это не компьютер под Вашим управлением).

Похож у Вас есть включенный Автор GSS из командной строки, как которая можно выключить его с чем-то ssh -o GSSAPIAuthentication=no user@host.example.com.

Если это работает, вероятно, было бы легче выключить для соединений по умолчанию путем добавления GSSAPIAuthentication no под Host * раздел Вашего ~/.ssh/config файл (или в масштабе всей системы ssh_config файл). При необходимости в нем для локальных серверов, можно затем добавить a Host *.my_company.com раздел со снова включенным.

6
задан 28 August 2012 в 15:57
3 ответа

Тщательно обдумайте, о чем вы просите, и решительно рассмотрите возможность этого не делать .

RFC 2616 указывает, что тела сущностей, которые вы хотите Remove должен присутствовать.

10.3.2 301 Moved Permanently

Новый постоянный URI ДОЛЖЕН быть указан в поле Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый (е) URI.

и ...

10.3.3 302 Found

Временный URI ДОЛЖЕН быть задан полем Location в ответе. Если метод запроса не был HEAD, объект ответа ДОЛЖЕН содержать короткую гипертекстовую заметку с гиперссылкой на новый (е) URI.

СЛЕДУЕТ, в этом контексте, определено в RFC 2119 :

Это слово или прилагательное " но есть еще древние чудовища, скрывающиеся в тени темных спален и туалетов центров обработки данных, и иногда они выходят, чтобы поиграть. Скорее всего, вы увидите curl , который все еще широко используется.

Эта рекомендация была несколько смягчена в RFC 7231 , в котором просто говорится (для обоих 301 и 302):

Полезные данные ответа сервера обычно содержат короткую гипертекстовую заметку с гиперссылкой на новый (е) URI.

Полезные данные ответа сервера обычно содержат короткую гипертекстовую заметку с гиперссылкой на другой (е) URI (ы).

9
ответ дан 3 December 2019 в 00:04

Это немного некрасиво, но, возможно, вы могли бы прокси 301/302 запросы и используйте proxy_method для изменения запросов GET на HEAD. Я не тестировал это, но запросы заголовков должны отправлять только заголовки без ответов или (надеюсь) заголовки content- *.

http://wiki.nginx.org/NginxHttpProxyModule#proxy_method

0
ответ дан 3 December 2019 в 00:04

Да, вы можете АБСОЛЮТНО сделать это с помощью NGINX!

  • Просто установите обработчик исключений, также известный как error_page , для последующей обработки требуемых ответов . Обязательно установите его таким образом, чтобы страница с ошибкой не изменяла код состояния HTTP, например, не используйте параметр = (или используйте его для жесткого кодирования любого желаемого кода).

  • Убедитесь, что возвращает ответ с кодом состояния возврата, который позволяет вам дополнительно установить [текст] , а не URL .

  • Укажите default_type of "" , который, похоже, удаляет заголовок Content-Type

Вот полный код, также в моем GitHub в репозитории StackOverflow.cnst.nginx.conf :

# cat sf.421976.301-302-redirect-w-no-http-body-text.nginx.conf | sed 's#^#\t#g'
server {
    listen 1976;
    error_page 301 302 @30x; # keep original HTTP status code w/o `=`
    location @30x {
        default_type ""; # will remove Content-Type completely
        # `300` is a filler: client will get the original HTTP status code
        return 300;
    }
    return 301 http://example.su/test;
}

Вот подтверждение, что он работает правильно:

% curl -i localhost:1976 | sed 's#^#\t#g'
HTTP/1.1 301 Moved Permanently
Server: nginx/1.2.1
Date: Mon, 28 Aug 2017 22:02:41 GMT
Content-Length: 0
Connection: keep-alive
Location: http://example.su/test

%

Я пробовал это в браузерах , и там тоже все работало нормально.

PS Другой вариант - изменить исходный код и отредактировать переменные ngx_http_error_301_page и др., Но зачем идти по жесткому пути ?! ^ _ ^

6
ответ дан 3 December 2019 в 00:04

Теги

Похожие вопросы