4.2. Допущения клиентов
Несмотря на то, что клиент является «автоматическим», он может делать некоторые предположения, присущие человеку. Например, многие клиенты предполагают, что любой хост, имя которого начинается с "www", является web-сервером, хотя такое предположение явно может быть ложным.
Кроме того, клиент связывает себя с протоколами, требуемыми для обмена данными с сервером. В результате он делает предположения о работе протоколов для связи с сервером. Эти предположения проявляются в реализации, когда игнорируются стандартные методы согласования, определенные протоколом, а взамен используется тот или иной набор правил, заложенных в программу и делающий свое заключение о согласовании параметров. Результатом этого зачастую является потеря интероперабельности, снижение уровня надежности или обретение пользователями негативного опыта.
- Алгоритм аутентификации
- Несмотря на поддержку протоколом множества методов аутентификации, клиент может предположить, что сервер всегда поддерживает только один метод, который, согласно протоколу, является опциональным. Например, клиент SIP, контактирующий с сервером SIP в домене, который используется для идентификации мобильных устройств (например, www.example.cellular) может предположить, что сервер необязательный поддерживает метод AKA [10] на основании доменного имени, используемого для доступа к серверу. Другим примером может служить web-клиент, предполагающий, что сервер с именем http.example.com поддерживает защищенный протокол HTTP over TLS [16].
- Форматы данных
- Несмотря на поддержку протоколом множества форматов передачи данных клиенту от сервера, клиент может предположить использование какого-то одного метода взамен применения меток содержимого и возможностей согласования, обеспечиваемых нижележащим протоколом. Например, клиент RTSP может предположить, что все аудио-данные, получаемые с сайта media.example.cellular, используют узкополосное кодирование. В качестве другого примера можно рассмотреть почтового клиента, который полагает, что почтовый сервер с именем mail.example.cellular поддерживает только текстовый формат сообщений вместо проверки заголовков MIME [11] в сообщении для определения реального типа.
- Расширения протокола
- Клиент может попытаться работать с сервером, используя необязательные расширения протокола. Однако при этом вместо реализации требуемой логики выбора расширений (fallback logic), клиент может сделать ложное допущение о поддержке сервером того или иного расширения. Примером может служить клиент SIP, который требует гарантированных откликов на свои запросы (RFC 3262 [17]), предполагая, что это расширение поддерживается сервером с именем sip.example.telecom. Более того, клиент не будет реализовать возможность отказа от дополнительных расширений (fallback behavior), определенную в RFC 3262, поскольку предполагает, что все серверы, с которыми он будет взаимодействовать, находятся в том же домене и, следовательно, поддерживают это расширение. Однако, если это предположение окажется ошибочным, клиент не сможет сделать ни одного телефонного звонка.
- Языки
- Клиент может поддерживать средства обработки текста в зависимости от языка этого текста. Вместо определения языка на основе маркеров в сообщении от сервера клиент может делать предположения о языке на основе доменного имени. Такие предположения зачастую оказываются ложными. Например, клиент может предположить, что текст web-страницы с сервера в национальном (ccTLD) домене .de содержат текст на немецком языке и попытаться перевести этот текст на финский язык. Результат явно ошеломит пользователя, если реальный текст будет написан на французском языке. К несчастью описанное поведение клиентов иногда бывает вызвано тем, что сервер не указывает корректно язык документов, полагая, что это необязательно. Этот пример показывает, как ложные допущения могут создавать порочный круг.