CONNECT манипулаторите в Node.js трябва да запазват head буфера
Работете със CONNECT сокета и head буфера в Node на границата между HTTP и тунела, запазвайки байтовете, вече прочетени след заглавките.
HTTP сървър в Node обработва обикновена прокси заявка чрез своя callback за заявката. CONNECT поема по друг път: сървърът излъчва connect със заявката, клиентския сокет и head буфер.
Това събитие е предаването между HTTP анализа и тунела. Няма обикновен обект ServerResponse, който да продължи да се използва за тунелния трафик.
| Аргумент | Какво носи |
|---|---|
req | CONNECT заявката, включително нейния целеви орган и заглавки |
clientSocket | Връзката обратно към клиента |
head | Тунелни данни, които Node вече е прочел след HTTP заглавките, възможно празни |
Завършете HTTP решението, преди да препредавате байтове
Валидирайте заявения хост и порт, приложете политиката за достъп и удостоверяване на проксито и установете връзката нагоре. CONNECT идентифицира орган като service.example:443; анализирайте тази форма с оглед на IPv6 органи, вместо сляпо да разделяте при всяко двоеточие.
Когато тунелът бъде приет, изпратете успешния HTTP отговор, последван от завършващия му празен ред. След това предайте всички head байтове нагоре, преди да продължите със следващите байтове от клиентския сокет. Прикачването на нов слушател за данни не може да възстанови буфер, който вече е бил отделно доставен на манипулатора.
Официалният пример за тунелиране на Node извършва това предаване с serverSocket.write(head), преди да свърже двете посоки на потока. Малкият пример илюстрира прехода; внедреното прокси се нуждае и от ограничени опити за връзка, контрол на достъпа и управление на жизнения цикъл.
След успех байтовете принадлежат на протокола на услугата
Успешният CONNECT отговор превръща връзката в байтов поток. Ако целта е HTTPS сайт, неговият TLS обмен пътува вътре в този поток. Самото тунелиране не изисква проксито да издава заместващ сертификат за сайта.
Преди приемането на CONNECT HTTP грешка може да обясни защо е отказано. След приемането записването на HTTP 500 в потока би инжектирало байтове в тунелния протокол. Вместо това прекратявайте или унищожавайте подходящите връзки при последващи откази.
Свържете двете посоки с управление на потока със съобразяване със задно налягане и решете как събитията end, error и close прекратяват партньора. Запазете първоначалния head буфер като част от същия модел на собственост; той е данни на приложението, а не излишни HTTP заглавки за изхвърляне.