The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ночных и бета сборках Firefox включена по умолчанию поддержка HTTP/3 , opennews (ok), 21-Мрт-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


96. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Урри (ok), 21-Мрт-21, 15:34 
> Читаем внимательно.

Попробуйте, пока у вас не вышло.


> Вы вообще не поняли что там написано и про что этот GUID.
> Это просто идентификатор, что сервер поддерживает WebSocket. Это не "ключ".

Вы не смогли осилить мой комментарий, правда? Я вам процитирую главное.

--- cut ---
Внимание, вопрос: почему в стандарте не написано "сгенерируйте текстовую строку из разрешенных символов? Почему не написано "к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"? Почему там требование ненужного base64 и ненужного guid?
--- cut ---

Строка "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" не GUID. Это просто строка, для конкатенирования к другой строке, принятой от клиента. Не к base64-кодированным данным, а к обычной строке, ведь декодирования не происходит. GUID - это 16 байт. Конкатенируемая "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" - это строка.


For this header field, the server has to take the value (as present
in the header field, e.g., the base64-encoded [RFC4648] version minus
any leading and trailing whitespace) and concatenate this with the
Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
95CA-C5AB0DC85B11

Перевод: сервер должен взять строку из заголовка и прибавить к ней другую строку. Все. Слова base64-encoded, RFC4648, GUID, RFC4122 совершенно лишние и вообще никакого смысла в данном случае не несут.

Не сервер должен декодировать base64 строку и добавить к ней сгенерированный guid. Нет. Сервер должен взять пришедшую строку и добавить к ней строку "258EAFA5-E914-47DA-
95CA-C5AB0DC85B11".

Клиент, который будет проверять ответ, тоже должен взять эти строки. Не свои случайно сгенерированные 16 байт, как написано в стандарте "The value of this header field MUST be a nonce consisting of a randomly selected 16-byte value that has been base64-encoded", а уже закодированную в base64 строку. Смысла в генерации этих байт по стандарту нет. Можно сразу генерировать строку похожую на base64 (из алфавита a..z=), от этого смысл ни на йоту не поменяется.

Теперь понимаете?

Ответить | Правка | Наверх | Cообщить модератору

111. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (80), 21-Мрт-21, 17:19 
По-порядку.

---> Почему не написано "к этой строке надо конкатенировать другую строку "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"

Ты английский не понимать? Я тебе прямым текстом цитату скинул в прошлый раз. Ещё раз, но попроще...

---> concatenate this with "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" in string form

----> сгенерируйте текстовую строку из разрешенных символов

Там не надо ничего генерировать.
Это уникальный идентификатор протокола, ты до сих пор этого не понял? Вернул эту строку - значит соответствует спецификации стандарта WebSocket.

---> Строка "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" не GUID
---> GUID - это 16 байт

GUID - это стандарт того, как генерировать "уникальный" идентификатор.

Если строка сгенерирована по спецификации - это GUID. Точка. Если другие строки будут сненериоованы по спецификации - шансы коллизий минимальны.

Или ты хочешь сказать что если я в коде сненерировал GUID и начал им пользоваться (и сервер / клиент / пользователь) увидел его - это уже не GUID?

Тут просто взяли и сгенерировали GUID и вставили в стандарт.

И это GUID ровно в том самом смысле - соответствует спецификации стандарта.

Открываем стандарт https://tools.ietf.org/html/rfc4122. Читаем...
---> The formal definition of the UUID string representation is...


"258EAFA5-E914-47DA-
95CA-C5AB0DC85B11" - это не строка. Это строковое представление GUID.

---> Внимание, вопрос: почему в стандарте не написано "сгенерируйте текстовую строку из разрешенных символов

Что там сервер будет "генерировать"?) Версию протокола? Ещё раз - этот GUID не определяет уникальность сервера, он определяет какой спецификации он соответствует. Поэтому он в тексте стандарта. Там могла быть любая, достаточно уникальная строка, типа "rfc-5432-websocket".

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

---> ведь декодирования не происходит

Не происходит.

Весь смысл base64 в этом ...
---> Base encoding of data is used to store or transfer data restricted to US-ASCII [1] data.

Base encoding can also be used in new applications that do not have legacy restrictions, simply because it makes it possible to manipulate objects with text editors.

Те чтобы ты мог легко декодировать данные, которые приходят по HTTP. Ведь HTTP это текстовый протокол. А данные могут передаваться по нему самые разные.

И этот base64 используется в сотнях, если не тысячах RFC для HTTP чтобы реально кодировать / декодировать данные. И HTTP клиенты / серверы уже имеют base64 кодировку. И есть куча библиотек для этой кодировки. Логично использовать её же, тк HTTP стандарты должны имееть преемственность и дружить друг с другом.

А тут приходит такой Вася - эксперт с opennet и говорит "Нинужна! Сложна!" надо "Можно сразу генерировать строку похожую на base64 (из алфавита a..z=)".

Те Вася предлагает НОВУЮ кодировку, "похожую". Под конкретно этот стандарт. Остальные заголовки будут приходит в base64, а этот "из алфавита a..z=".

А потом ещё одну, под другой...и ещё одну...

Хорошо что стандарты пишут "говноделы из Google", а не "эксперты с opennet". Надеюсь что так и дальше останется.


Ответить | Правка | Наверх | Cообщить модератору

117. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Урри (ok), 21-Мрт-21, 17:36 
Мда. Сплошнолй фейспалм. Ordu выше и то умнее выступил.

Что я могу на все это ответить? Только одно: "Прекрасная иллюстрация #2 озвученного в первом комментарии тезиса. Даже более красноречивая, чем #1".

Очередной эффект Даннинга-Крюгера.

Ответить | Правка | Наверх | Cообщить модератору

119. "В ночных и бета сборках Firefox включена по умолчанию поддер..."  +/
Сообщение от Аноним (80), 21-Мрт-21, 17:49 
Ну вот Васе и нечего по-сути ответить, по спецификации.


Вася не умеет внимательно читать и, тем более, понимать спецификации.

Вась, признавайся, эникейщиком работаешь али в отделе кадров засидаешь.

Твой технический и экспертный уровень понятен. Он... сколько таких "Вась-экспертов" с opennet.

На джуниора не тянешь. Проходи повышение квалификации, может я тебя к себе может возьму.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру