Во-первых, спасибо за внимание и терпение в разборе этого вопроса всем участникам.
Во-вторых, Отденльная благодарность RomikChef, его следут признать победителем двух конференций.
Прилагаю также сам эрфс в котором к сожалению про концы строк пишут непонятно. CLRF это, по-моему, один конец строки. Хотя в статьях про заголовки я читал, что заголовок запроса от тела должен отделяться двумя переводами. Даже я это уже пробовал, но видимо что-то было не так. И когда уже в многократный раз перенабил запрос, то получил правильный результат.
5 Запрос (Request).
Сообщение запроса от клиента к серверу содержит в первой строке: метод, который нужно применить к ресурсу, идентификатор ресурса и используемую версию протокола.
Request = Request-Line ; Раздел 5.1
*( general-header ; Раздел 4.5
| request-header ; Раздел 5.3
| entity-header ) ; Раздел 7.1
CRLF
[ message-body ] ; Раздел 7.2
5.1 Строка запроса (Request-Line).
Строка запроса (Request-Line) начинается с лексемы метода, затем следует запрашиваемый URI (Request-URI), версия протокола и CRLF. Эти элементы разделяются SP. В строке запроса (Request-Line) не допустимы CR и LF, исключение составляет конечная последовательность CRLF.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1 Метод (Method).
Лексема метода указывает метод, который нужно применить к ресурсу, идентифицированному запрашиваемым URI (Request-URI). Метод чувствителен к регистру.
Method = "OPTIONS" ; Раздел 9.2
| "GET" ; Раздел 9.3
| "HEAD" ; Раздел 9.4
| "POST" ; Раздел 9.5
| "PUT" ; Раздел 9.6
| "DELETE" ; Раздел 9.7
| "TRACE" ; Раздел 9.8
| extension-method
extension-method = token
Список методов, применимых к ресурсу, может быть указан в поле заголовка Allow (раздел 14.7). Возврашаемый код состояния ответа всегда сообщает клиенту, допустим ли метод для ресурса в настоящее время, так как набор допустимых методов может изменяться динамически. Серверам СЛЕДУЕТ возвратить код состояния 405 (Метод не дозволен, Method Not Allowed), если метод известен серверу, но не применим для запрошенного ресурса, и 501 (Не реализовано, Not Implemented), если метод не распознан или не реализован сервером. Список методов, известных серверу, может быть указан в поле заголовка ответа Public (раздел 14.35).
Методы GET и HEAD ДОЛЖНЫ поддерживаться всеми универсальными (general-purpose) серверами. Остальные методы опциональны; однако, если вышеупомянутые методы реализованы, то они ДОЛЖНЫ иметь семантику, описанную в разделе 9.
5.1.2 Запрашиваемый URI (Request-URI).
Запрашиваемый URI (Request-URI) - это Единообразный Идентификатор Ресурса (URL, раздел 3.2), который идентифицирует ресурс запроса.
Request-URI = "*" | absoluteURI | abs_path
Три опции для запрашиваемого URI (Request-URI) зависят от характера запроса. Звездочка "*" означает, что запрос обращается не к специфическому ресурсу, а к серверу непосредственно, и допускается только в том случае, когда используемый метод не обязательно обращается к ресурсу. В качестве примера:
OPTIONS * HTTP/1.1
absoluteURI необходим, когда запрос производится через прокси-сервер. Прокси-сервер перенаправляет запрос на сервер или обслуживает его, пользуясь кэшем, и возвращает ответ. Обратите внимание, что прокси-сервер МОЖЕТ переслать запрос другому прокси-серверу или непосредственно серверу, определенному absoluteURI. Чтобы избежать зацикливания запроса прокси-сервер ДОЛЖЕН быть способен распознавать все имена сервера, включая любые псевдонимы, локальные разновидности, и числовые IP адреса. Request-Line может быть, например, таким:
GET
http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Чтобы обеспечить переход к absoluteURI во всех запросах в будущих версиях HTTP, все HTTP/1.1 серверы ДОЛЖНЫ принимать absoluteURI в запросах, хотя HTTP/1.1 клиенты будут генерировать их только в запросах к прокси-серверам.
Наиболее общая форма Request-URI - та, которая используется для идентификации ресурса на первоначальном сервере или шлюзе. В этом случае абсолютный путь URI (смотрите раздел 3.2.1, abs_path) ДОЛЖЕН быть передан как Request-URI, а сетевое расположение URI (net_loc) ДОЛЖНО быть передано в поле заголовка Host. Для последнего примера клиент, желающий получить ресурс непосредственно с первоначального сервера должен создать TCP соединение на 80 порт хоста "
www.w3.org" и послать строки:
GET /pub/WWW/TheProject.html HTTP/1.1
Host:
http://www.w3.orgи далее остаток запроса. Обратите внимание, что абсолютный путь не может быть пустым; если оригинальный URI пуст, то он ДОЛЖЕН запрашиваться как "/" (корневой каталог сервера).
Если прокси-сервер получает запрос без пути в Request-URI, и метод запроса допускает форму запроса "*", то последний прокси-сервер в цепочке запросов ДОЛЖЕН передать запрос, в котором Request-URI равен "*". Например запрос
OPTIONS
http://www.ics.uci.edu:8001 HTTP/1.1
был бы передан прокси-сервером в виде
OPTIONS * HTTP/1.1
Host:
http://www.ics.uci.edu:8001после соединения с портом 8001 хоста "
www.ics.uci.edu".
Request-URI передается в формате, определенном в разделе 3.2.1. Первоначальный сервер ДОЛЖЕН декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверам СЛЕДУЕТ отвечать на недопустимые Request-URI соответствующим кодом состояния.
В запросах, которые передаются далее, прокси-сервера никогда НЕ ДОЛЖНЫ перезаписывать часть "abs_path" запрашиваемого URI (Request-URI), за исключением случая, отмеченного выше, когда пустой abs_path заменяется на "*", независимо от внутренней реализации прокси-сервера.
Обратите внимание: правило "ничто не перезаписывать" предохраняет прокси-сервера от изменения значения запроса, в котором первоначальный сервер неправильно использует не зарезервированные символы URL для своих целей. Реализаторам следует знать, что некоторые до-HTTP/1.1 прокси-сервера, как известно, перезаписывали Request-URI.
5.2 Ресурс, идентифицируемый запросом.
Первоначальные HTTP/1.1 сервера ДОЛЖНЫ учитывать, что точный ресурс, идентифицированный интернет-запросом определяется исследованием как Request-URI, так и поля заголовка Host.
Первоначальный сервер, который не позволяет ресурсам отличаться по запрошенному хосту (host), МОЖЕТ игнорировать значение поля заголовка Host. (Но смотрите раздел 19.5.1 для других требований по поддержке Host в HTTP/1.1).
Первоначальный сервер, который различает ресурсы, основанные на запрошенном хосте (иногда называемые виртуальными хостами или vanity hostnames) ДОЛЖЕН использовать следующие правила для определения запрошенного в HTTP/1.1 запросе ресурса:
Если Request-URI - это absoluteURI, то хост - это часть Request-URI. Любое значение поля заголовка Host в запросе ДОЛЖНО игнорироваться.
Если Request-URI - не absoluteURI, а запрос содержит поле заголовка Host, то хост определяется значением поля заголовка Host.
Если хоста, определенного правилами 1 или 2 не существует на сервере, код состояния ответа ДОЛЖЕН быть 400 (Испорченный Запрос, Bad Request).
Получатели HTTP/1.0 запроса, в котором недостает поля заголовка Host, МОГУТ пытаться использовать эвристику (например, исследовать путь в URI на предмет уникальности на каком-либо из хостов) чтобы определить какой точно ресурс запрашивается.
5.3 Поля заголовка запроса.
Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса с семантикой, эквивалентной параметрам вызова методов в языках программирования.
request-header = Accept ; Раздел 14.1
| Accept-Charset ; Раздел 14.2
| Accept-Encoding ; Раздел 14.3
| Accept-Language ; Раздел 14.4
| Authorization ; Раздел 14.8
| From ; Раздел 14.22
| Host ; Раздел 14.23
| If-Modified-Since ; Раздел 14.24
| If-Match ; Раздел 14.25
| If-None-Match ; Раздел 14.26
| If-Range ; Раздел 14.27
| If-Unmodified-Since ; Раздел 14.28
| Max-Forwards ; Раздел 14.31
| Proxy-Authorization ; Раздел 14.34
| Range ; Раздел 14.36
| Referer ; Раздел 14.37
| User-Agent ; Раздел 14.42
Имена полей заголовка запроса (Request-header) могут быть надежно расширены только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику полей заголовка запроса (Request-header), если все стороны соединения распознают их как поля заголовка запроса (Request-header). Нераспознанные поля заголовка обрабатываются как поля заголовка объекта (entity-header).
Как видно из эрфс про двойной конец строки речи небыло
