Но это лишь затравка (уж простите, нелюбители долгобукв). Сам сок происходит в методе App.AutoHTTPS(), который инициализирует tls листенер, в который прокидывает сертификаты автоматически. Проверяет, вешают автохттпс на домен ли, чтобы сунуть автосерт, а вот если вешают на ip адрес - ну, с летсэнкриптом (дефолтным провайдером у автосерта) сертификаты не выпишешь. Нет домена - нет сертификата. Вроде логично. На IP адреса я самостоятельно серты выписываю. Спойлер - идея плохая, для этого есть mkcert, который юзает локальный CA, чтобы браузеры меньше на говно исходили.

Ну и вот это - есть костыль. Я, например, намеренно упустил возможность того, что туда сунут ипв6, потому что имплементировать банально лень. Да и я без понятия, как оно себя поведёт, если сунуть туда чужой домен. Скорее всего, просто зафейлится tls.NewListener(), и тогда, если немного подождать, завершится и tcp листенер, после чего работа будет завершена. Но это лишь предположение. Проблема лишь в том, что самым выгодным решением будет, убрать нахер все те проверки "а домен ли это" (задача не так проста, как кажется на первый взгляд) и просто пытаться выписать с ACME себе сертификаты на переданный адрес. Не получится - значит, берём mkcert. Собственно, так я сделать и хочу - возможно даже, заменив по пути autocert на lego. Но там блоата многовато (автосерту почтение - всё в одну кнопку делается), придётся для начала говно разгребсти ещё. Но выглядит поинтереснее, честно говоря. За киллерфичу, конечно, хотелось бы выдать, да только кому нынче хттпс в вебфреймворке нужен. Каждый первый дебил дальше нжинкса его и не нюхал. Жаль.

Но меня сейчас интересует другое. Серты с летсэнкрипта выписываются на 90 дней. То есть, каждые полтора месяца нужно их обновлять. Тут есть 2.5 варианта, как мне это делать:
1) DNS челленджи. Это когда в TXT поле кладёшь специально составленную строку, которая включает в себя токен от летсэнкрипта. Таким образом, сервис может быть уверен, что мы правда владеем доменом.
2) http и alpn челленджи. По сути, оба монофаллические, просто alpn через tls идёт. С http суть проста - открываешь на вебсервере ресурс /.well-known/acme-challenge/<token>, где token - как раз таки тот токен, который тебе летсэнкрипт и даст. За этим ресурсом должен лежать файл, в котором будет содержаться инфа по регистрации, и сам токен.

Собственно, я люблю циферки. Я на них дрочу, неистово, с неподдельным возбуждением. И мне становится очень грустно, перезагружать вебприложение каждые полтора месяца, чтобы обновлять сертификаты, тем самым теряя месячные аптаймы. Чисто технически, можно совершенно без проблем обновлять их на ходу - на момент обновления, просто делаем доступным такой ресурс на сервере, и кладём туда нужные данные. Получаем сертификаты - перезагружаем тлс листенер (да, клиентам придётся испытать тряску, но разрыв подключения на одну секунду раз в полтора месяца не смертелен; кому смертелен - тот будет использовать днс челленджи). Вуаля! Теперь индига может спокойно работать годами безостановочно. Один лишь недостаток - мне тогда придётся половину ACME самостоятельно имплементировать, чтобы это всё себе интегрировать. И хуже всего как раз таки с днс челленджами тогда придется - но, думается мне, здесь уж можно будет оставить ответственность на пользователе. А вынести метод "App.RenewCertificate()` мне всё равно придется, если я действительно буду это делать. И тогда уж точно можно будет киллерфичей назвать - пускай это и заботы реверс-прокси, зато можно будет теперь индигу саму как реверс-прокси ставить:)

Тогда уж надо будет столько всего интересного добавлять, дабы оно всё работало сносно и удобно. Но это уже тема совершенно иных лонгридов...

bro writing a text for school

Bro writing about the most unnecessary feature of his pet-project with 46 likes:

Та ебать

Вот у меня сущность приложения (indigo.App) довольно тупая, и принимает роутер только когда жмакают app.Serve(). Поэтому, на сколько портов индигу не вешай, роутер будет один и тот же использоваться. Из-за этого и появился virtual.Router, который берёт запрос, и перенаправляет его в соответствующий роутер. Но мне вот какая мысль пришла: это ведь можно и более элегантно реализовать!

Вот я навешиваю аппу на разные порты через App.Bind(addr). Я могу сюда же роутер и прокидывать! Всё равно на каждом порту свой листенер (каждый в своей горутине), тогда ещё и косты на виртуальный роутинг сводятся к нулю (сейчас там перебор массива на каждый запрос, в надежде, что доменов будет немного - если меньше 7, тогда норм). Но и прокидывать в прям каждый App.Bind() роутер отдельно не хочется (например, аргумент пришлось бы дублировать в ситуациях, когда я хочу навесить аппу на хттп и хттпс). Есть вариант - если в бинде не указан роутер, будет использован роутер, указанный в предыдущем бинде. Либо дефолтный (который будет передаваться так, как передается и сейчас - через App.Serve(r)). Сохраняется обратная совместимость, но общий Developer Experience ухудшается - какая-то магия, везде вариадики.

Но, сука, фича-то сладкая, так и манит гадина. Я сейчас и так тот единственный переданный роутер в аппу передаю каждому листенеру по отдельности, а листенер у меня - замыкание, поэтому, возможно, можно будет добавить какую-нибудь заглушку а-ля App.Bind(":8081", Virtual(TCP, r2)), где r2 - это роутер для какого-нибудь другого домена от переданного в последующий App.Serve(r). Не без дизайнерских проблем, но и с TLS тоже зафурыкает.

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

За хотдоги спасибо, но у меня тут забавная ситуация. Я начал тыкать напрямую net.ListenTCP, чтобы иметь не-виртуальный метод SetDeadline() на листенере. Нюанс в том, что конструктор принимает *net.TCPAddr, который сначала надо ещё получить. Получаешь через net.ResolveTCPAddr(). А в него нельзя засунуть 0.0.0.0 - заглушка, которая слушает на всех интерфейсах - в отличии от net.Listen. Там, почему-то, всё работает нормально. И я всё никак вдуплить не могу, где именно здесь происходит эта магия

А, нет, я дегенерат. Я блять адрес передавал в ListenTCP() вместо network. А должен был литерал "tcp". Ну теперь-то ебать работает

На каждую операцию чтения либо записи в сокет, я указываю дедлайн - таймаут, после которого операция зафейлится. При чтении я, например, таким образом могу отсекать idle подключения. Там нужно указывать абсолютное значение: ну, то есть, вот это вот time.Now().Add(90*time.Second). И я заметил, что это как-то... Дороговато! 50нс, если быть точным. Дорого, потому что я обычно в 500-600нс суммарно укладываюсь, вместе с парсингом, обработкой и формированием ответа

Не то, чтобы это особо интересно было, просто довольно занятный кейс. Я это дело оптимизировал посредством atomic.Int64, в который кладу раз в 500мс текущее время из отдельной горутины. 55нс превратились в 5.6нс. Нраица!

this is REAL Unicode emoji proposal done by REAL people

3 лучших контрибьютора в индиго

Да это же литералли ми

https://zero.sci-hub.se/5268/7dda7cee52d7eb3ec606a82d0f1b9a61/giertsen1988.pdf

Забавная ситуация с мгновенной декомпрессией 9 атмосфер. А вот фото человека, в следствии поместившегося в зазор 12.7см, уже не такое забавное

У двоих, которые спали в соседней камере, в мгновение вскипела кровь и мозги. Интересно, можно ли это записать в тихую смерть во сне?

Я всё ещё жду, когда кто-то поставит сюда огоньки

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

Pentium 1993 года, 3.1млн транзисторов. Над непосредственно кремнием 3 слоя проводок и соединений

Таки 6 огоньков наставили. Какие же вы аморальные пидорасы