Beast નું CONNECT બફર TLS હેન્ડશેકમાં લઈ જાઓ

Beast એ પ્રોક્સીનું CONNECT પ્રતિસાદ હેડર વાંચ્યા પછી, પ્રતિસાદની સ્થિતિ અને ગતિશીલ બફર બંનેની તપાસ કરો. વાંચન ક્રિયા હેડરના અંત પછીના બાઇટ્સ લાવી શકે છે અને તેમને આપેલા બફરમાં રાખી શકે છે. ફક્ત સૉકેટ વાંચતા ઓવરલોડ સાથે TLS શરૂ કરો તો એ રાખેલા બાઇટ્સ TLS ઇનપુટ માર્ગની બહાર રહે છે.

જે WebSocket સ્ટ્રીમનું આગળનું સ્તર SSL સ્ટ્રીમ છે તેના માટે બફરવાળું હેન્ડશેક ઓવરલોડ વાપરો. હાલની yield_context સેશનમાં, buffer ને બધી ક્રિયાઓ દરમિયાન જીવંત રાખીને:

http::response_parser<http::empty_body> response;
http::async_read_header(
    beast::get_lowest_layer(ws), buffer, response, yield[ec]);
if (ec) return;

auto status = response.get().result_int();
if (status < 200 || status >= 300) return;

std::size_t used = ws.next_layer().async_handshake(
    ssl::stream_base::client, buffer.data(), yield[ec]);
if (ec) return;
buffer.consume(used);

શરૂઆતના રિટર્ન સેશનના નિષ્ફળતા નિકાસ છે; ત્યાં સામાન્ય ભૂલ નોંધણી અને સફાઈ જોડો. ફક્ત સફળ CONNECT પ્રતિસાદ જ ટનલ સ્થાપે છે. અસ્વીકાર પૃષ્ઠ TLS ઇનપુટ ન બનવું જોઈએ.

બફરવાળું ઓવરલોડ ભૂલ કોડ અને બાઇટ ગણતરી સાથે પૂર્ણ થાય છે. એ ગણતરી કહે છે કે તેણે આપેલા બફરમાંથી કેટલા બાઇટ્સ વાપર્યા. પૂર્ણ થયા પછી consume(used) થી બરાબર એ પ્રીફિક્સ દૂર કરો. ક્રિયા શરૂ કરતાં પહેલાં બફર સાફ ન કરો, હેન્ડશેક બાકી હોય ત્યારે તેનું સંગ્રહસ્થાન ન બદલો, અને ક્રિયાએ આપેલા દરેક બાઇટ વાપર્યા છે એમ ન માનો.

CONNECT પછી તરત ક્લાયન્ટ-શરૂ કરેલા સામાન્ય TLSમાં બફર ખાલી હોઈ શકે. ઓવરલોડ એ કેસ પણ સંભાળે છે. તેનો હેતુ સ્ટ્રીમ સીમાઓ જાળવવાનો છે; તે કોઈપણ વધારાના પ્રોક્સી ડેટાને માન્ય TLS બનાવતું નથી. હેન્ડશેક પહેલાં SSL સ્તર પર લક્ષ્ય હોસ્ટનામ ચકાસણી અને SNI ગોઠવણી રાખો, અને TLS સફળ થયા પછી જ WebSocket અપગ્રેડ શરૂ કરો.