19.3. Допустимые приложения
Хотя этот документ определяет требования генерации HTTP/1.1 сообщения, не, все приложения будут правильны в своей реализации. Мы поэтому рекомендуем, чтобы операционные приложения были терпимы к отклонениям всякий раз, когда те отклонения могут быть интерпретированы однозначно.
Клиенты ДОЛЖНЫ быть терпимыми в парсинге Линии состояния и серверов, терпимых, разбирая Линию запроса. В частности они ДОЛЖНЫ принять любое количество символов SP ИЛИ HT между полями, даже при том, что только отдельная ИСПАНИЯ требуется.
Признак конца линии для полей заголовка сообщения — последовательность CRLF.
Однако, мы рекомендуем, чтобы приложения, разбирая такие заголовки, распознали отдельный перевод строки как признак конца линии и проигнорировали межстрочный интервал CR.
Символьный набор тела объекта не должен быть маркирован как самый низкий общий знаменатель символьных кодов, используемых в пределах того тела, за исключением того, что никакой, метка предпочтена по меткам US-ASCII или ISO-8859-1.
Дополнительные правила для требований при парсинге и кодировании дат и других потенциальных проблем с кодированиями даты включают:
- HTTP/1.1 клиенты и кэши должен предположить, что RFC-850 дат, которые оказываются больше чем 50 годами в будущем, находятся фактически в прошлом (это помогает решать проблему "года 2000").
- HTTP/1.1 реализация может внутренне представить разобранную дату Expires как ранее чем собственное значение, но не ДОЛЖЕН внутренне представить разобранную дату Expires как позже чем собственное значение.
- Весь expiration связанные вычисления нужно сделать в GMT. Локальный часовой пояс не ДОЛЖЕН влиять на вычисление или сравнение времени expiration или возраста.
- Если заголовок HTTP неправильно несет значение даты с часовым поясом кроме GMT, он нужно преобразовать в GMT, используя самое консервативное преобразование.