Authors’ addresses rfc 2068


Содержание

HTTP 1.1 — Русский перевод спецификации RFC 2068.

Автор: Alex A. Simonoff (Leshik@omsk.com)

Network Working Group
Request for Comments: 2068
Category: Standards Track
R. Fielding
UC Irvine
J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
Январь 1997.

ПРОТОКОЛ ПЕРЕДАЧИ ГИПЕРТЕКСТА
HTTP/1.1

О переводе.

Эдесь представлен перевод документа RFC 2068 на русский язык. При переводе я пользовался личным опытом и здравым смыслом, поэтому в некоторых местах читатель, знакомый с оригиналом, может заметить несущественные отличия. Я изо всех сил пытался придать удобочитаемый вид, но в некоторых местах вы встретите предложения, написанные «криво» (это связано либо с «техничностью» текста, либо с моими проблемами в русском языке). Убедительная просьба : если встретите опечатки, ошибки, или у вас появятся предложения по улучшению отдельных фраз или целых фрагментов — сообщите мне по адресу Leshik@omsk.com.

Я отдаю себе отчет в том, что некоторые термины, возможно, переведены некорректно. При сомнениях я добавлял английские термины в круглых скобках. Например: запрос (request).

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

ТЕКСТОВАЯ ВЕРСИЯ ЗДЕСЬ.

ОРИГИНАЛ ЗДЕСЬ.

Статус данного документа.

Этот документ определяет протокол дорожки стандартов Интернета для семейства Интернета, и предназначен для обсуждения и предложений по усовершенствованию. Пожалуйста обратитесь к текущему изданию «Официальные стандарты протоколов Интернет» (STD 1) для выяснения состояния стандартизации и состояния этого протокола. Распространение данного документа неограничено.

Реферат.

Протокол передачи Гипертекста (HTTP) — протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. Это общий, платформно-независимый, объектно-ориентированный протокол, который может использоваться во многих задачах, таких как сервера имен и распределенные системы управления объектами, посредством расширения методов запроса.

Возможность HTTP — это печать и обсуждение представления данных, позволяющее строить системы независимо от передаваемых данных.

HTTP используется в World Wide Web (WWW) начиная с 1990 года. Эта спецификация определяет протокол, упоминаемый как «HTTP/1.1».

Что такое заголовки в протоколе HTTP.

Когда мы разбирали общую структуру HTTP запросов и ответов, то одной из частей, из которой эта структура состояла, являлись HTTP заголовки (Message Headers). Давайте сейчас подробнее рассмотрим, что это такое.

Заголовки – это специальные параметры, которые несут определенную служебную информацию о соединении по HTTP. Некоторые заголовки имеют лишь информационный характер для пользователя или для компьютера, другие передают определенные команды, исходя из которых, сервер или клиент будет выполнять какие-то действия.

В зависимости от того, где эти заголовки могут находиться, они разделяются на:

General Headers (Основные заголовки) — должны быть и в запросах и в ответах клиента и сервера.

Request Headers (Заголовки запроса) — используются только в запросах клиента.


Response Headers (Заголовки ответа) — используются только в ответах сервера.

Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

Каждый заголовок имеет следующий вид:

Немного о правилах написания, что нужно иметь в виду:

1) Регистр (большие или маленькие буквы) здесь не учитываются. Можно писать и так и так.

2) Пишутся латинскими буквами.

3) После параметра должен идти символ двоеточия (:)

4) Окончанием пары «параметр:значение» служит символ переноса строки.

Вот, примеры некоторых заголовков:

На самом деле, количество возможных заголовков, которые можно указать, очень большое. Я не вижу смысла приводить их все здесь.

Если вы знаете английский, то почитать о них можно в оригинале на страницах стандарта HTTP 1.1.

Кроме того, есть перевод этого стандарта на русский язык здесь:

Есть еще хорошая табличка, которая опубликована на страницах википедии:

Кстати, если хотите узнать конверсии и ключевые показатели (KPI) для вашего продающего сайта, могу настроить веб-аналитику.

Яндекс Метрика и Google Analytics. Цели, события, отчеты.

RFC 2068 — Протокол Передачи Гипертекста — HTTP/1.1

Страница 1 из 160

Статус данного документа

Этот документ определяет протокол дорожки стандартов Интернета (Internet standards track protocol) для семейства Интернета, и предназначен для обсуждения и предложений по усовершенствованию. Пожалуйста обратитесь к текущему изданию «Официальных стандартов протоколов Интернет» (STD 1) для выяснения состояния стандартизации и статуса этого протокола. Распространение данного документа неограничено.

Тезисы

Протокол передачи Гипертекста (HTTP) — протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. Это общий, платформно-независимый, объектно-ориентированный протокол, который может использоваться во многих задачах, таких как сервера имен и распределенные системы управления объектами, посредством расширения методов запроса.


Возможность HTTP — это печать и обсуждение представления данных, позволяющее строить системы независимо от передаваемых данных. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Эта спецификация определяет протокол, упоминаемый как «HTTP/1.1».

Содержание

1 Введение

1.1. Цель

Протокол передачи Гипертекста (HTTP) — протокол прикладного уровня для распределенных, совместных, многосредных информационных систем. HTTP используется в World Wide Web (WWW) начиная с 1990 года. Первой версией HTTP, известной как HTTP/0.9, был простой протокол для передачи необработанных данных через Интернет. HTTP/1.0, как определено в RFC 1945 [6], был улучшением этого протокола, позволяя сообщениям иметь MIME-подобный формат, содержащий метаинформацию о передаваемых данных и имел модифицированную семантику запросов/ответов. Однако, HTTP/1.0 недостаточно хорошо учитывал особенности работы с иерархическими прокси-серверами (hierarchical proxies), кэшированием, постоянными соединениями, и виртуальными хостами (virtual hosts). Кроме того, быстрое увеличение не полностью совместимых приложений, называющих тот протокол, который они использовали «HTTP/1.0», потребовало введения версии протокола, в которой были бы заложены возможности, позволяющие приложениям определять истинные возможности друг друга.

Эта спецификация определяет протокол «HTTP/1.1». Этот протокол содержит более строгие требования, чем HTTP/1.0, гарантирующие надежную реализацию возможностей.

OpenRate.us

Сайт про CRM-маркетинг, рассылки и вот это всё

Разбираемся со служебными заголовками электронной почты

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

Где найти служебные заголовки email в интерфейсах Mail.Ru, Яндекс.Почте и Gmail, смотрите здесь.

Стандартные служебные заголовки электоронной почты

Илон Маск рекомендует:  Что такое код sizeof

Cc: — Carbon Copy — заголовок является расширением поля «To:», он указывает дополнительных получателей письма. Некоторые почтовые программы рассматривают «To:» и «Cc:» по-разному, генерируя ответ на сообщение.

Content-Transfer-Encoding: — MIME-заголовок, не имеет отношения к доставке почты, отвечает за то, как программа-получатель интерпретирует содержимое сообщения.

MIME — стандартному метод помещения в письмо нетекстовой информации (см. в Википедии).

Content-Type: — MIME-заголовок, сообщающий почтовой программе о типе данных, хранящихся в сообщении.

Date: — дата создания сообщения. Не стоит принимать на веру из-за возможности подделки или ошибки во времени у отправителя.

Errors-To: — адрес для отсылки автоматических сообщений об ошибках. Большинство отправителей обычно хотят получать сообщения об ошибках на исходящий адрес, который используется почтовыми серверами по умолчанию.

From (без двоеточия) — конвертный заголовок «From» формируется на базе информации, полученной от команды MAIL FROM. Например, если отправляющая машина говорит MAIL FROM: 123@123.com, получающая машина сгенерирует строчку следующего вида: «From 123@123.com»

! Конвертный заголовок создается не отправителем сообщения, а компьютером, через который прошло это сообщение.

From: (с двоеточием) информация об адресе отправителя, указанная самим отправителем.


Message-Id: — более или менее уникальный идентификатор, присваиваемый каждому сообщению, чаще всего первым почтовым сервером, который встретится у него на пути. Обычно он имеет форму «blablabla@domen.ru», где «blablabla» может быть абсолютно чем угодно, а вторая часть — имя машины, присвоившей идентификатор. Иногда, но редко, «blablabla» включает в себя имя отправителя.

Если структура идентификатора нарушена (пустая строка, нет знака @) или вторая часть идентификатора не является реальным интернет-сайтом, значит письмо — вероятная подделка.

Также Message-id: или Message-ID:.

In-Reply-To: — заголовок Usenet, который иногда появляется и в письмах. «In-Reply-To:» указывает идентификатор некоего сообщения, на которое данное сообщение является ответом. Этот заголовок нетипичен для писем, если только письмо действительно не является ответом на сообщение в Usenet. Спаммеры иногда им пользуются, возможно, чтобы обойти фильтрующие программы.

Mime-Version: или MIME-Version: — MIME-заголовок, обозначающий версию MIME-протокола, который использовался отправителем.

Organization: — свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети.

Priority: — свободный заголовок, устанавливающий приоритет сообщения. Большинство программ его игнорируют. Часто используется спаммерами в форме «Priority: urgent» с целью привлечения внимания к сообщению.

Received: — содержит информацию о прохождении письма через почтовый сервер. Анализируя заголовок «Received:», мы видим, кто его отправил и какой путь оно проделало, попав в наш ящик.

Reply-To: — указывает адрес, на который следует посылать ответы. Несмотря на то, что этот заголовок имеет множество способов цивилизованного применения, он также используется спаммерами для отведения гневных ответов получателей спама от себя.

Return-Path: — адрес возврата в случае неудачи, когда невозможно доставить письмо по адресу назначения. Обычно совпадает с MAIL FROM. Но может и отличаться.

Subject: — тема сообщения.

To: — адрес получателя (или адреса). При этом поле «To:» может не содержать адреса получателя, так как прохождение письма базируется на конвертном заголовке «To», а не на заголовке сообщения «To:».

X-заголовки

Это отдельный набор заголовков, начинающихся с заглавной X с последующим дефисом. Существует договоренность, согласно который X-заголовки являются нестандартными и добавляются только для дополнительной информации. Поэтому нестандартный информативный заголовок должен иметь имя, начинающееся на «X-«. Эта договоренность, однако, часто нарушается.

X-Confirm-Reading-To: — заголовок запрашивает автоматическое подтверждение того, что письмо было получено или прочитано. Предполагается соответствующая реакция почтовой программы, но обычно он игнорируется.

X-Errors-To: — заголовок указывает адрес, на который следует отсылать сообщения об ошибках. Он реже соблюдается почтовыми серверами.

X-Mailer: или X-mailer: — свободное поле, в котором почтовая программа, с помощью которой было создано данное сообщение, идентифицирует себя (в рекламных или подобных целях). Поскольку спам часто рассылается специальными почтовыми программами, это поле может служить ориентиром для фильтров.

X-Priority: — еще одно поле для приоритета сообщения.

X-Sender: — почтовый аналог Usenet-заголовка «Sender:». Предполагалось, что он будет доставлять более надежную информацию об отправителе, чем поле «From:», однако в действительности его так же легко подделать.

X-UIDL: — уникальный идентификатор, используемый в POP-протоколе при получении сообщений с сервера. Обычно он добавляется между почтовым сервером получателя и собственно почтовой программой получателя. Если письмо пришло на почтовый сервер уже с заголовком «X-UIDL:», это скорее всего спам — очевидной выгоды в использовании заголовка нет, но спаммеры иногда его добавляют.

Еще служебные заголовки

List-Unsubscribe: — читайте здесь.


X-Mras: служебный заголовок Mail.Ru, фиксирующий наличие или отсутствие спама в письме на основе разработанной в Mail.Ru системы фильтрации спама — MRAS (Mail.Ru Anti-Spam).

List-id: — служебный заголовок для сбора статистики по отдельным письмам в Почтовом офисе Яндекса.

X-Mailru-Msgtype: — аналогичный «List-id:» заголовок для Postmaster@Mail.Ru.

X-PMFLAGS: и X-Distribution: — специфические заголовки программы Pegasus Mail.

Sender: — нетипичен для писем (обычно используется «X-Sender:»), иногда появляется в копиях Usenet-сообщений. Предполагает идентификацию отправителя, в случае с Usenet-сообщениями является более надежным, чем строчка «From:».

Comments: — заголовок не является стандартным, может содержать любую информацию. Чаще всего используется в виде «Comments: Authenticated sender is ».

References: — редко используется в почтовых сообщениях, за исключением копий Usenet-сообщений. Он используется в Usenet для прослеживания «дерева ответов», к которому принадлежит сообщение. Если он появился в письме, то это письмо является копией Usenet-сообщения или почтовый ответ на Usenet-сообщения.

Newsgroups: — используется в письмах, связанных с Usenet: либо в копии отправленного в Usenet сообщения, или в ответе на эти сообщения. В первом случае он указывает конференцию, в которые сообщение было послано, а во втором — конференции, в которые было послано сообщение, на которое данное письмо является ответом.

Apparently-To: — сообщения с большим количеством получателей иногда имеют длинный список заголовков вида «Apparently-To: 123@domen.ru» (по одной строчке на получателя). Эти заголовки нетипичны для нормальных сообщений, они обычно являются признаком массовой рассылки.

Bcc: — Blind Carbon Copy, слепая копия. Если вы видите этот заголовок в полученном сообщении, значит, «что-то пошло не так». Этот заголовок используется так же, как и «Cc:», но не должен появляться в списке заголовков.

Префикс Resent- может быть добавлен при пересылке письма. Например, «Resent-From:» или «Resent-To:». Такие поля содержат информацию, добавленную тем, кто переслал сообщение:

Поле «From:» содержит адрес первоначального отправителя.

«Resent-From:» — адрес переславшего.

Представление заголовков письма в наглядном формате с помощью гугловского приложения.

Большая часть заголовков взята в статье на antispam.ru. Почитайте, там интересно.

Разбираемся со служебными заголовками электронной почты : 1 комментарий

Спасибо за статью! А есть информация, как можно добавить заголовки для постмастера/постофиса в Mailchimp?

RFC 2068 statement about HTTP

In RFC 2068, it states, «[HTTP] is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.»

Can someone elaborate on what those adjectives mean in regards to HTTP?

Илон Маск рекомендует:  Шаблон сайта магазина подарков HTML, CSS, JS

1 Answer 1


generic (section 15.4):

Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request.

Authors’ addresses / rfc 2068

Request for Comments: 2616
Obsoletes: 2068
Category: Standards Track
June 1999
UC Irvine J. Gettys (Compaq/W3C), J.Mogul (Compaq), H. Frystyk (W3C/MIT)
L. Masinter (Xerox), P. Leach (Microsoft), T. Berners-Lee (W3C/MIT).
Hypertext Transfer Protocol — HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the «Internet Official Protocol Standards» (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1999). All Rights Reserved.

From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1:

‎06-05-2010 12:56 PM

Everytime i try to connect to the interntet I get «From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1 :» Can anyone help me?

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Flag Post

From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1:


‎06-06-2010 06:47 AM — edited ‎06-06-2010 07:49 AM

You shouldn’t get that message as a common user at home.

«It’s actually asking for a port number, such as HTTP/1.1:80.»

edit: I have noticed that it happens just in IE8. try Firefox, Opera or Chrome, it might be ok..

Dv6-7000 Debian Buster
HP Touchpad provided by HP
HP Microserver Gen8 10TB Debian Server

*Please, help other users with the same issue by marking your solved topics as «Accept as Solution»*

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из строки запроса (ответа), сопровождаемой вспомогательными строками заголовка и тела. Строки заголовка отделяются друг от друга парой символов . Тело отделяется от заголовков пустой строкой. Заголовки могут быть любой длины, и сервер обязан либо обработать длинный заголовок, либо выдать соответствующий код ошибки. Тело запроса (ответа) представляет последовательность байтов, на которую не накладывается никаких ограничений.

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

Послав запрос и заголовки, клиент может отправить дополнительные данные. Эти данные используются главным с методом POST для передачи .

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

После заголовка отправляются затребованные данные. Если запрос клиента удовлетворить нельзя, передается сообщение об ошибке в приемлемом для чтения человеком виде.

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:


Максимальная длина строки параметров при реализации может быть ограничена как со стороны клиента, так и со стороны сервера.

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

  • время изменения документа;
  • размер документа;
  • тип документа;
  • тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

В запросе клиент должен передать URI запрашиваемого документа. Это может быть сделано в абсолютной или относительной форме. В первом случае в состав URI должны входить название протокола и имя сервера.

Во втором случае передается только путь к документу.

В этом случае имя и порт хоста, может быть передано в строке заголовка Host:

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

Передача данных в ответе сервера


Несколько заголовков используемых в ответе сервера, позволяют точно описать формат и размер передаваемых данных.

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

Серверы используют типы сообщения в заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое

В типе сообщения для текстовых форматов может быть указана использованная кодировка.

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

Большое значение в реализации протокола HTTP имеет уведомление клиента о размере данных в теле ответа, т.к. в силу 8 битовости протокола тело ответа не может сопровождаться каким либо ограничителем.

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Илон Маск рекомендует:  Что такое код str_repeat

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

А тело сообщения строится по следующим правилам

Признаком завершения передачи является кусок нулевой длины.

Следует отметить, что символы в конце куска, не являются его частью. Подобное кодирование очень удобно в тех случаях, когда размер данных заранее неизвестен, и достаточно велик.

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

RFC (Request for Comments)

RFC (англ. Request for Comments — Рабочее предложение) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации ISOC (англ. Internet Society, ISOC ). Правами на RFC обладает именно Общество Интернета.

Содержание

История

Формат RFC появился в 1969 году при обсуждении проекта ARPANET. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.

Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса (UCLA).


С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC институту информационных наук Университета Южной Калифорнии.

Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.

Содержимое RFC

Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь — проект). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:

  1. Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
  2. Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
  3. Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
  4. Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
  5. Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)

Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:

  1. Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
  2. Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
  3. Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.

Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).

Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.

Производство и эволюция

Редактор RFC присваивает каждому RFC в серийный номер . После того, как присваивается номер и опубликован RFC, RFC никогда не аннулируется или измененяется; если документ требует внесения поправок, авторы публикуют пересмотренный документ. Таким образом, некоторые RFC вытесняют другие; замененный RFC называются устаревшим или замененным RFC. Вместе пронумерованные RFC составляют непрерывную запись истории эволюции стандартов и практик Интернет. Процесс RFC описан в RFC 2026 (Процесс стандартизации Интернет, пересмотренный вариант 3)

Процесс производства RFC отличается от стандартизации процесса формальных организаций по стандартизации , таких как ISO . Эксперты интернет технологий не могут представить интернет-проект без поддержки со стороны внешнего учреждения. Стандарты RFC публикуются с одобрения IETF, и, как правило, производятся специалистами, участвующими в рабочих группах, которые сначала публикуют интернет-проект. Такой подход облегчает начальный этап рецензирования документов, прежде чем превращается в RFC.

Большинство RFC используют общий набор терминов, таких как «ДОЛЖЕН» и «НЕ РЕКОМЕНДУЕТСЯ» (как определено в RFC 2119 ), дополненной Бэкуса-Наура (ABNF) ( RFC 5234 ) в качестве мета-языка, и простого текстового формата для того, чтобы содержать RFC последовательным и понятным. [1]

Подсерии

Серия RFC содержит три подсерии для IETF RFC:

BCP (Best Current Practice) обязательные IETF RFC не стандартным путем.

FYI (For Your Information) информационные RFC, продвигаемые IETF , как указано в RFC 1150 (FYI 1). В 2011 году RFC 6360 устарел FYI 1 и завершил подсерию.

STD (Standard) Раньше это был третий и самый завершенный из IETF стандартов, указанный в RFC 2026 (BCP 9). В 2011 году RFC 6410 (новая часть BCP 9) снизил стандарты.

From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1:

‎06-05-2010 12:56 PM

Everytime i try to connect to the interntet I get «From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1 :» Can anyone help me?

  • Mark as New
  • Bookmark
  • Subscribe
  • Subscribe to RSS Feed
  • Permalink
  • Print
  • Email to a Friend
  • Flag Post

From RFC 2068 Hypertext Transfer Protocol — HTTP/1.1:

‎06-06-2010 06:47 AM — edited ‎06-06-2010 07:49 AM

You shouldn’t get that message as a common user at home.

«It’s actually asking for a port number, such as HTTP/1.1:80.»

edit: I have noticed that it happens just in IE8. try Firefox, Opera or Chrome, it might be ok..

Dv6-7000 Debian Buster
HP Touchpad provided by HP
HP Microserver Gen8 10TB Debian Server

*Please, help other users with the same issue by marking your solved topics as «Accept as Solution»*

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL