Bewarje bufferde gegevens nei in HTTP CONNECT-antwurd
Foarkom in fêstlope HTTP CONNECT-hânhânjeling troch de grins fan 'e antwurdheaders te finen en de bytes dy't dêrnei komme te bewarjen.
In lytse proxy-wrapper kin wurkje foar HTTPS en dan hingje as er opnij brûkt wurdt foar in protokol wêrfan't de tsjinner earst praat. De fertochte rigel is faak dyjinge dy't wachtet oant de ûntfangstbuffer einiget mei \r\n\r\n.
TCP jout de klant in stream. Ien ûntfangstoprop kin de helte fan in HTTP-statusrigel weromjaan, in folslein CONNECT-antwurd, of dat antwurd daliks folge troch tunnelgegevens. Der is gjin garânsje dat in lêzing by de ein fan 'e headers ophâldt.
Fyn de grins yn 'e buffer
Foar in HTTP/1.1 CONNECT-útwikseling sammelje jo bytes oant de header-einmarkearring earne yn 'e buffer ferskynt. Splitsje by de earste foarkommen. Parsearje de statusrigel en headers út it earste part; bewarje alles nei de grins apart. Pas in limyt foar header-grutte en in timeout ta by it wachtsjen, en behannelje in lege socket-lêzing as in sletten ferbining ynstee fan in nije útnoeging om te loopen.
In definitive slagge 2xx-antwurd set de ferbining daliks nei dy headers yn tunnelmodus. De bytes dêrnei binne al tunnelbytes. Goai se net fuort, wachtsje net op in CONNECT-antwurdlichem, en ynterpretearje in Content-Length-fjild net as tastimming om in part fan it nije protokol te konsumearjen. Ynformative antwurden, as dy der binne, moatte foar dat definitive antwurd behannele wurde.
De wrapper moat syn oerbliuwsels trochjaan
Allinnich de ûnderlizzende socket weromjaan ferliest de bytes dy't de hânhânjeling-parser der al út helle hat. De folgjende lêzer hat in bufferde stream nedich dy't earst de bewarre sturt jout en dan socket-lêzingen werombegjint. Foar in protokol wêrby't de tsjinner earst praat, kin it ferliezen fan dy earste groet beide kanten ûneinich litte wachtsjen.
Oarsom binne bytes fan in mislearre CONNECT-antwurd gjin tunnelgroet. In 407 heart noch altyd by de proxy-útwikseling en freget om autentikaasjebehanneling; in oare net-slagge status freget in passend flaterpaad.
Dit is benammen fan belang by it oanpassen fan in FTP- of SSH-klant fia in HTTP-proxy. De proxy moat ek de frege bestimmingspoarte tastean, en FTP kin ekstra gegevensferbiningen nedich hawwe. Krekte header-parsing lost de stream-oerdracht op; it kin gjin CONNECT-tastimming jaan of it twadde kanaal fan FTP leverje.