Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+1
function test() {
const ws = new WebSocket('ws://127.0.0.1:445');
ws.addEventListener('close', event =>
console.log('event.code = ', event.code, '; event.reason = ', event.reason)
);
ws.close(3500, 'some reason');
}
test();
Кто угадает значения полей event.code и event.reason — тому два нихуя.
Кто угадает значение одного из полей — тому одно нихуя.
Запостил: 
ISO,
10 Февраля 2022
Follow us!
UPD: в качестве подсказки разрешается почитать https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/close.
Нет.
> Ведь в close аргументы для отправки на сервер?
Нет.
> Нет.
А для чего они тогда, если не для отправки Close Frame серваку?
Explaining to whom? Не самому себе же?
локализовать удобно
блядь, что за проблемы как в PHP в 1999м году?
Нинужно.
This data is not necessarily human readable but may be useful for debugging or passing information relevant to the script that opened the connection. As the data is not guaranteed to be human readable, clients MUST NOT show it to end users.
?
Кстати, за локализацию ошибок сотрудники Microsoft и авторы PostgreSQL будут гореть в аду миллард лет.
> This data is not necessarily human readable
Вангую
https://github.com/Luka967/websocket-close-codes
CLOSED_NO_STATUS або Unsupported payload ли CLOSE_PROTOCOL_ERROR
На самом деле есть, только эта связь — ID.
Реальный пример:
Ничего не подозревающий веб-петух пишет логику для ручного разрыва вебсокетов, в функции для восстановления связи после обрыва проверяет, что обрыв не был ручным… А потом получает вечный цикл, потому что проверка работает только тогда, когда ручной разрыв происходит у уже подключённого сокета. И ведь в 99% случаях всё прекрасно работает, сука!
Или под "ручным" имеется в виду разрыв со стороны сервера, когда сервак явно говорит "уходи и не возвращайся"?
И да, это не я писал, я в этом баг искал.
Ну х.з. как оно там прекрасно работает. Целый раундтрип должен пройти успешно чтобы разрыв зафиксировался. Любая проблема в любой промежуточной точке от отправки до получения -- добро пожаловать в вечный реконнект.
И самое главное -- а нафиг всё это, если можно просто флаг заюзать?
Потому что асинхронщина во все поля. Заебёшься с флагами.
Деталь реализации конкретного сервака ведь...
Т.е. для мультиплексирования всё равно будут какие-то внешние или внутренние хедера. И не было никакого смысла усложнять протокол.
https://datatracker.ietf.org/doc/html/draft-ietf-hybi-websocket-multiplexing
Дык там ещё и сами сообщения на фреймы побиты. Внутри потока, побитого на TLS фреймы, побитые на TCP фреймы. Интересно, насколько эффективно вся эта срань взаимодействует и не налетает ли она на какие-нибудь лаги в духе знаменитого send-send-receive.
Сегменты же. Фреймы канают только на канальном уровне.
> TCP фреймы
Дык к ним на уровне ОС доступа нет. Для пользователя (программы) TCP — это чистый поток байт.
Кууууик
Да. Собственно, «WebSocket» так и делает.
> А причем mime бондари к TCP?
Потому что mime бондари — это блядский костыль, возникший из-за того, что «HTTP» принципиально не умеет в разделение одного запроса на логические сообщения, а «HTTP» это не умеет в том числе и потому, что TCP — это ёбанный поток байт.
Почтовое сообщение мало того, что должно быть семибитным, так еще и должно в этом тексте как-то передать сообщение и аттачи.
https://datatracker.ietf.org/doc/html/rfc1521
А уже оттуда он перекочевал в веб
Ладно, ладно, потому что mime бондари — это блядский костыль, возникший в «HTTP» из-за того, что «HTTP» принципиально
Я всё ещё не могу без ёбанного мультипарта послать один POST на /crud/kurochka, в котором у меня будут лежать три фотографии курочки.
А один POST это как одна транзакция.
Ну то есть руками шукать бондари в куче говна не нужно, если ты не пишеш свой фреймворк
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/multipart/MultipartFile.html
Всё таки "в джаве делают руками" может оказаться слишком сильным утверждением
Да, я могу послать эти три фотки тремя запросами, только вот:
1. На сервере вместо одной простой курочки появляется новая сущность — «незаконченная курочка». Её нельзя отдавать в GET, нужно обновлять через POST (привет, грубое нарушение сёмантики), и хуй знает, что делать, если клиент пошлёт PUT.
2. А где мы будем хранить незаконченных курочек — в БД (уродуем таблицы, добавляем флаги/нуллабельность/новые таблицы для незаконченных сущностей...) или в памяти сервера (нужно писать кучу дополнительного говна в репозиториях)?
3. А что мы будем делать с незаконченными курочками?
4. А как мы будем финализировать курочек?
Вместо простой и понятной модели — «один запрос — одна сущность» — у нас появляется море дерьма.
Если нужен протокол для создания курочек на сервере, то логично придумать ему расширение для посылки массива курочек
> Если нужен протокол для создания курочек на сервере, то логично придумать ему расширение для посылки массива курочек
Ну дык вот это мультидерьмо баундри — это оно и есть, расширение для посылки массива курочек.
И изначально я плевался на то, что сделанный в «TCP» «поток байт» — это никому не нужное дерьмо. Оно нужно разве что для педерачи аудиовизуальной информации, и то не нужно, потому что все вменяемые видеосерверы поток бьют на куски нужной длины. В реальности же 99.9% времени по сети гоняются сообщения переменной длины — HTTP-запросы, уебсокет-фреймы, you name it. И чтобы их передавать по ёбанному потоку байт — каждая макака придумывает свой протокол, один охуительнее другого. И именно поэтому я за «UDP» (был бы, если бы не ограничение на размер датаграм).
Только больному, душному, максимально оторванному от реальности деду могла прийти в голову мысль о том, что «поток байт» — это хорошая, годная высокоуровневая абсракция.
Дед не виноват же, что все запутались во фрагментации, хакеры стали ее юзать для ddosа, и фрагментацию отменили, и теперь сообщения ширше MTU не пролазят.
А HTTP просто не по назначению юзают же
У проводного ethernet 1500, но если поверх него запустить VPN (некоторые провайдеры любят L2TP запустить) то он станет меньше..
Так-то размер пакета максимальный вроде 64K (ну минус заголовки там всякие) но MTU, увы
Деды просто любили городить уровни, и предполагали, что ты поверх потока байт запилишь т.н. ``framing protocol'', который эти байты разобьёт на логические сообщения неком способом, удобным для твоей бизнес логики. Это упрощает транспортный уровень, т.к. ему не нужно думать про размеры буферов в твоей рукоприкладной питушне. Решение вполне в духе многоуровневой модели.
TCP придумали в 80е, когда скорость арпанетов была в килобитах в секунду, и про оверхед такого решения никто не думал, скорее всего.
Деды так-то дали возможнасць вообще любой протокол поверх IP пулять, просто NAT сильно ограничил выбор протоколов
>разбивать на многочлены.
так-то MSS же, ТЦП это и делает. Толще MTU все равно ничего не пролезет. Знаете, сколько слез было пролито из за MTU blackhole, когда пинги идут, а сайты открываются наполовину?
Вы призвали летающую голову Fike.
Что не отменяет того факта, что попытка создать курочку атомарно посредством HTTP это попытка закрутить гвоздь стамеской. Но смузихлёбы придумали, а программисты теперь страдают
S3 и аналоги всё стерпят. У меня почему-то такое ощущение, что всякие вконтакты и фейсбуки навсегда сохраняют загруженную фотку в хранилище даже если её потом передумают постить...
Юзер заливает фотки по одной, а затем отдельным атомарным запросом постит их урлы и описание.
не городить же MVCC в хранилке
Причём не как-то, а чтобы юзер не охуел! Всё должно быть более-менее читаемо даже на старых клиентах, которые не умеют эти ваши MIME.
Тащить всё это в HTTP, разумеется, не стоило.
Подключится не успели?
Как ой баг ор )) )