Отправка формы перенаправляется

#php #.htaccess #encoding #apache2

#php #.htaccess #кодирование #apache2

Вопрос:

Я получаю это странное поведение из всех браузеров при попытке отправить эту форму. В этой форме всего 2 поля: заголовок и текст статьи. Форма по умолчанию имеет значение application/x-www-form-urlencoded. При отправке сайт иногда отвечает 404.

Приведенный ниже журнал взят непосредственно из заголовков HTTP в реальном времени.

http://www.faulty-domain.com/article-page 

СООБЩЕНИЕ / страница статьи HTTP/1.1 
Хост: www.faulty-domain.com 
Пользовательский агент: Mozilla / 5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.9.2.23) Gecko / 20110920 Firefox /3.6.23 ( .NET CLR 3.5.30729) 
Принимаем: текст / html, приложение / xhtml   xml, application / xml;q=0.9,*/*;q = 0.8 
Принять-Язык: en-us,en;q=0.5 
Принять-Кодировка: gzip, deflate 
Принять кодировку: ISO-8859-1, utf-8; q = 0.7,*;q = 0.7 
Сохранить работоспособность: 115 
Соединение: поддерживается 
Реферер: http://www.faulty-domain.com/article-page 
Тип содержимого: application/x-www-form-urlencoded 
Длина содержимого: 3288 
blog_title=Статья   Заголовок   для   сохранения amp; newsbody=

The текущая бла бла бла

Найден HTTP / 1.1 302 Дата: Вт, 08 ноября 2011 12:42:23 GMT Сервер: Apache /2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passsthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.14 X-Powered-By: PHP / 5.2.14 Срок действия: Чт, 19 ноября 1981 г. 08:52:00 по ГРИНВИЧУ Управление кэшем: нет хранилища, нет кэша, необходимо повторно проверять, после проверки = 0, предварительная проверка=0 Pragma: нет кэша Местоположение: http://www.faulty-domain.com/notFound Содержимое-Кодировка: gzip Изменить: Принять-Кодирование Содержание-Длина: 26 Соединение: закрыть Тип содержимого: текст /html

Страница пытается отправить сама себе, затем предполагается проверить, был ли метод post, и различные проверки проверки, обычные вещи. Но тогда http-ответ представляет собой страницу 404 not found (не найдена).

Наш внутренний фреймворк работает как Code Igniter, так что все запросы будут выполняться index.php . Очевидно, что веб-сервер даже не пытался выполнить index.php но на основании заголовков запроса каким-то образом решил, что ответом должно быть 404.

Теперь я выполнил свою собственную отладку и поиграл со статьей, которую отправляю. Я попытался добавлять статью абзац за абзацем и посмотреть, в каком абзаце возникает ошибка. Форма нормально отправляется до определенного абзаца, в этот момент я сказал Бинго! Я думал, что изолировал проблему и попытался отправить форму, используя только этот абзац, но затем форма была отправлена. Что теперь меня озадачивает, почему веб-сервер принимает это как есть, но если добавить в конец исходной статьи, это сходит с ума!

Возможно, это связано с htaccess или веб-сервером, но я просто не смог разобраться с этой штукой.

Обновить:

Для всех тех, кто запросил просмотр отправляемых данных post, вот ссылка. Я удалю файл примерно через неделю.http://www.globalpropertyguide.com/temp/faulty-article.html

Вот часть htaccess, которая может помочь. В основном наш index.php определяет, какой контроллер вызывать, на основе того, какое значение получает $mod.

 RewriteRule ^([^/] )/$ /$1 [R]
RewriteCond %{QUERY_STRING} !mod= [NC]
RewriteRule ^([^/] )$ /index.php?mod=$1 [L]
  

Кроме того, если когда-либо это могло бы помочь, это ошибка, которая регистрируется в apache error_log

 "POST /write-article HTTP/1.1" 302 26 "http://www.faulty-domain.com/write-article" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24 ( .NET CLR 3.5.30729)"
"GET /notFound HTTP/1.1" 404 7635 "http://www.faulty-domain.com/write-article" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24 ( .NET CLR 3.5.30729)"
  

Комментарии:

1. @Phil, действительно, но если мы посмотрим поближе на раздел заголовка ответа, местоположение — это страница, которую не удалось найти. Я нажимаю, когда сервер решил, что с запросом что-то не так, он перенаправил запрос на 404. Я могу ошибаться.

2. Как выглядит .htaccess? Возможно ли, что именно фреймворк инициирует перенаправление? Не так уж много можно сказать о «работает как Code Igniter».

3. @nachito, я добавил некоторую информацию, которая может помочь в дальнейшем решении проблемы

Ответ №1:

Вы должны выяснить, кто перенаправляет вас и почему. Было бы действительно полезно, если бы вы просто обновили свой вопрос, добавив текст, который вы пытаетесь опубликовать, но что-то пошло не так, и текст равного размера, который будет принят.

Это может произойти в PHP. Может быть какая-то проверка длины или плохих слов, которая приводит к ошибочному перенаправлению. Также может быть активен какой-то плагин Apache, который делает то же самое.

Комментарии:

1. Я добавил некоторую информацию, которая может помочь в решении проблемы

2. Я обновил ссылку faulty-article.html . Пожалуйста, просмотрите ее исходный код, поскольку на этот раз я разместил к нему комментарии.

3. Перейдите к lipsum.com сгенерируйте несколько абзацев и попробуйте опубликовать их. Опять же, никто не может догадаться об этом за вас. Я дал несколько подсказок (посмотрите в вашем PHP-коде и конфигурации Apache).