Зачувајте ги баферираните податоци по одговорот HTTP CONNECT
Избегнете заглавено HTTP CONNECT ракување со наоѓање на границата на заглавјата на одговорот и зачувување на бајтите што пристигнуваат по неа.
Мал прокси-обвивка може да работи за HTTPS, а потоа да се заглави кога ќе се употреби повторно за протокол чиј сервер зборува прв. Сомнителната линија обично е онаа што чека баферот за прием да заврши со \r\n\r\n.
TCP му дава на клиентот тек. Еден повик за прием може да врати половина HTTP статусна линија, целосен CONNECT одговор или тој одговор веднаш следен со тунелски податоци. Нема ветување дека читањето ќе запре на крајот од заглавјата.
Најдете ја границата во баферот
За HTTP/1.1 CONNECT размена, собирајте бајти додека завршетокот на заглавјата не се појави било каде во баферот. Поделете на неговото прво појавување. Парсирајте ја статусната линија и заглавјата од првиот дел; сè по границата чувајте го одделно. Применете ограничување на големината на заглавјата и временско ограничување додека чекате, а празното читање од сокетот третирајте го како затворена врска, а не како уште една покана за вртење во циклус.
Конечниот успешен 2xx одговор веднаш по тие заглавја ја префрла врската во тунелски режим. Бајтите што го следат веќе се тунелски бајти. Не ги отфрлајте, не чекајте тело на CONNECT одговор и не толкувајте го полето Content-Length како дозвола да се потроши дел од новиот протокол. Информативните одговори, ако ги има, мора да се обработат пред тој конечен одговор.
Обвивката мора да ги предаде своите остатоци
Враќањето само на основниот сокет ги губи бајтите што парсерот за ракување веќе ги извлекол од него. Следниот читач бара бафериран тек што прво ја дава зачуваната опашка, а потоа ги продолжува читањата од сокетот. За протокол во кој серверот зборува прв, губењето на тој почетен поздрав може да ги остави двете страни да чекаат бесконечно.
Обратно, бајтите од неуспешен CONNECT одговор не се тунелски поздрав. 407 сè уште и припаѓа на прокси размената и бара обработка на автентикација; друг неуспешен статус бара соодветна патека за грешка.
Ова е особено важно при прилагодување на FTP или SSH клиент преку HTTP прокси. Проксито исто така мора да го дозволи бараниот одредишен порт, а FTP може да бара дополнителни податочни врски. Правилното парсирање на заглавјата го решава предавањето на текот; тоа не може да даде CONNECT дозвола или да го обезбеди вториот канал на FTP.