HTTP CONNECT പ്രതികരണത്തിന് ശേഷം ബഫറിലുള്ള ഡാറ്റ സൂക്ഷിക്കുക

ചെറിയ ഒരു പ്രോക്സി റാപ്പർ HTTPS-ന് പ്രവർത്തിച്ച്, സർവർ ആദ്യം സംസാരിക്കുന്ന പ്രോട്ടോക്കോളിനായി വീണ്ടും ഉപയോഗിക്കുമ്പോൾ തൂങ്ങിക്കിടക്കാം. സംശയാസ്പദമായ വരി പലപ്പോഴും സ്വീകരണ ബഫർ \r\n\r\n ഉപയോഗിച്ച് അവസാനിക്കാൻ കാത്തിരിക്കുന്ന വരിയാണ്.

TCP ക്ലയന്റിന് ഒരു സ്ട്രീം നൽകുന്നു. ഒരു സ്വീകരണ കോൾ പകുതി HTTP സ്റ്റാറ്റസ് ലൈനോ, പൂർണ്ണമായ CONNECT പ്രതികരണമോ, അല്ലെങ്കിൽ ആ പ്രതികരണത്തെ തുടർന്ന് ഉടൻ ടണൽ ഡാറ്റയോ നൽകിയേക്കാം. വായന ഹെഡറുകളുടെ അവസാനത്തിൽ നിർത്തുമെന്ന് യാതൊരു ഉറപ്പുമില്ല.

ബഫറിനുള്ളിൽ അതിർത്തി കണ്ടെത്തുക

HTTP/1.1 CONNECT കൈമാറ്റത്തിന്, ഹെഡർ അവസാന ചിഹ്നം ബഫറിൽ എവിടെയെങ്കിലും പ്രത്യക്ഷപ്പെടുന്നതുവരെ ബൈറ്റുകൾ ശേഖരിക്കുക. അതിന്റെ ആദ്യ സംഭവത്തിൽ വിഭജിക്കുക. ആദ്യ ഭാഗത്തുനിന്ന് സ്റ്റാറ്റസ് ലൈനും ഹെഡറുകളും പാഴ്സ് ചെയ്യുക; അതിർത്തിക്ക് ശേഷമുള്ളതെല്ലാം വെവ്വേറെ സൂക്ഷിക്കുക. കാത്തിരിക്കുമ്പോൾ ഹെഡർ വലിപ്പ പരിധിയും സമയപരിധിയും പ്രയോഗിക്കുക, കൂടാതെ ശൂന്യമായ സോക്കറ്റ് വായനയെ ലൂപ്പിലേക്കുള്ള മറ്റൊരു ക്ഷണമായല്ല, അടച്ച കണക്ഷനായി കണക്കാക്കുക.

അവസാനത്തെ വിജയകരമായ 2xx പ്രതികരണം ആ ഹെഡറുകൾക്ക് ശേഷം ഉടൻ കണക്ഷനെ ടണൽ മോഡിലേക്ക് മാറ്റുന്നു. അതിന് ശേഷം വരുന്ന ബൈറ്റുകൾ ഇതിനകം ടണൽ ബൈറ്റുകളാണ്. അവ ഉപേക്ഷിക്കരുത്, CONNECT പ്രതികരണ ബോഡിക്കായി കാത്തിരിക്കരുത്, കൂടാതെ Content-Length ഫീൽഡിനെ പുതിയ പ്രോട്ടോക്കോളിന്റെ ഒരു ഭാഗം ഉപയോഗിക്കാനുള്ള അനുമതിയായി വ്യാഖ്യാനിക്കരുത്. വിവരദായക പ്രതികരണങ്ങൾ ഉണ്ടെങ്കിൽ അവ ആ അവസാന പ്രതികരണത്തിന് മുൻപ് കൈകാര്യം ചെയ്യണം.

റാപ്പർ അതിന്റെ ബാക്കിയുള്ളവ കൈമാറണം

അടിസ്ഥാന സോക്കറ്റ് മാത്രം തിരികെ നൽകുന്നത് ഹാൻഡ്ഷേക്ക് പാഴ്സർ ഇതിനകം അതിൽനിന്ന് വലിച്ചെടുത്ത ബൈറ്റുകൾ നഷ്ടപ്പെടുത്തുന്നു. അടുത്ത വായനക്കാരന് ആദ്യം സൂക്ഷിച്ച വാൽ നൽകി പിന്നീട് സോക്കറ്റ് വായന പുനരാരംഭിക്കുന്ന ബഫർ ചെയ്ത സ്ട്രീം ആവശ്യമാണ്. സർവർ-ആദ്യ പ്രോട്ടോക്കോളിൽ ആ പ്രാരംഭ അഭിവാദ്യം നഷ്ടപ്പെടുന്നത് ഇരുവശങ്ങളെയും അനന്തമായി കാത്തിരിക്കാൻ വിടാം.

നേരെമറിച്ച്, പരാജയപ്പെട്ട CONNECT പ്രതികരണത്തിലെ ബൈറ്റുകൾ ടണൽ അഭിവാദ്യമല്ല. 407 ഇപ്പോഴും പ്രോക്സി കൈമാറ്റത്തിന്റെ ഭാഗമാണ്, കൂടാതെ പ്രാമാണീകരണ കൈകാര്യം ആവശ്യമാണ്; മറ്റൊരു പരാജയ സ്റ്റാറ്റസിന് ഉചിതമായ പിശക് പാത ആവശ്യമാണ്.

HTTP പ്രോക്സി വഴി FTP അല്ലെങ്കിൽ SSH ക്ലയന്റ് ക്രമീകരിക്കുമ്പോൾ ഇത് പ്രത്യേകിച്ച് പ്രധാനമാണ്. പ്രോക്സി ആവശ്യപ്പെട്ട ലക്ഷ്യ പോർട്ടും അനുവദിക്കണം, FTP-ക്ക് അധിക ഡാറ്റ കണക്ഷനുകൾ ആവശ്യമായി വന്നേക്കാം. ശരിയായ ഹെഡർ പാഴ്സിംഗ് സ്ട്രീം കൈമാറ്റം പരിഹരിക്കുന്നു; അതിന് CONNECT അനുമതി നൽകാനോ FTP-യുടെ രണ്ടാം ചാനൽ നൽകാനോ കഴിയില്ല.