Squid-ന് ബ്രൗസറിനോട് തിരഞ്ഞെടുത്ത HTTP URL HTTPS വഴി വീണ്ടും ശ്രമിക്കാൻ ആവശ്യപ്പെടാം. ലക്ഷ്യസ്ഥാനം ഇതിനകം അതത് റിസോഴ്സ് HTTPS വഴി നൽകുന്നതായിരിക്കണം; Raspberry Pi-യിൽ Squid പ്രവർത്തിപ്പിക്കുന്നത് വെബ്സൈറ്റിൽ ആ കഴിവ് സൃഷ്ടിക്കുന്നില്ല.

Squid 7-ന്റെ url_rewrite_program ഇന്റർഫേസിനായി, helper ഇതുപോലൊരു ക്ലയന്റ് റീഡയറക്ട് നൽകാം:

OK status=307 url="https://www.example.com/help"

ഇത് പൊരുത്തപ്പെടുന്ന അഭ്യർത്ഥനയ്ക്കുള്ള ഒരു ഉദാഹരണ helper പ്രതികരണമാണ്, പൂർണ്ണ helper പ്രോഗ്രാമല്ല. ബ്രൗസർ റീഡയറക്ട് സ്വീകരിച്ച് HTTPS URL-ലേക്ക് പുതിയ അഭ്യർത്ഥന നടത്തുന്നു. അപ്ഗ്രേഡ് നയത്തിന് പുറത്തുള്ള URL-ന് OK ലഭിച്ച് മാറ്റമില്ലാതെ തുടരാം.

HTTPS-കഴിവുള്ള ലക്ഷ്യസ്ഥാനങ്ങളുടെ അറിയപ്പെടുന്ന പട്ടിക ഉപയോഗിച്ച് വരുന്ന URL വിശകലനം ചെയ്യുക. ഉദ്ദേശിച്ച പാതയും query-യും സംരക്ഷിക്കുക, വ്യക്തമായ പോർട്ടുകൾ കണക്കിലെടുക്കുക, അഭ്യർത്ഥനാ രീതികൾ ബോധപൂർവം കൈകാര്യം ചെയ്യുക. ഓരോ http പ്രിഫിക്സും കണ്ണടച്ച് മാറ്റുന്നത് ഓരോ ഒറിജിനും തുല്യമായ HTTPS സേവനമുണ്ടെന്ന് അനുമാനിക്കുന്നു.

ഇൻസ്റ്റാൾ ചെയ്ത Squid പതിപ്പിന്റെ പ്രോട്ടോക്കോൾ അനുസരിച്ച് helper ഓരോ ഇൻപുട്ട് വരിക്കും ഉത്തരം നൽകണം. സമകാലിക helper ചാനലുകൾ പ്രവർത്തനക്ഷമമാണെങ്കിൽ, മറുപടിയിൽ ചാനൽ ഐഡന്റിഫയർ നിലനിർത്തുക. പഴയ നഗ്നമായ 301:URL ഉദാഹരണം നിലവിലെ result-and-key/value ഫോർമാറ്റുമായി പരസ്പരം മാറ്റാനാകില്ല.

ബ്രൗസർ പുതിയ URL അറിയേണ്ടിവരുമ്പോൾ ക്ലയന്റ് റീഡയറക്ട് തിരഞ്ഞെടുക്കുക. rewrite-url പ്രതികരണം പകരം Squid-നോട് ക്ലയന്റിന്റെ യഥാർത്ഥ അഭ്യർത്ഥനയ്ക്ക് പിന്നിൽ മറ്റൊരു URL കൊണ്ടുവരാൻ ആവശ്യപ്പെടുന്നു, ഇത് ആപ്പിന്റെ URL-കളും അവസ്ഥയും പൊരുത്തക്കേടിലാക്കാം.

ആദ്യ HTTP അഭ്യർത്ഥന helper-ന് റീഡയറക്ട് ചെയ്യുന്നതിന് മുമ്പുതന്നെ Squid-ലേക്ക് എത്തിയിട്ടുണ്ട്. ഈ നയത്തിന് ആ അഭ്യർത്ഥന പിന്നോട്ട് സംരക്ഷിക്കാനാവില്ല. TLS അടുത്ത HTTPS കണക്ഷനിൽ ആരംഭിക്കുന്നു; ഒരു CONNECT ടണൽ മാത്രം എൻക്രിപ്ഷൻ നൽകുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ