શું Squid નો URL ફરીથી લખનાર પ્રતિસાદના મુખ્ય ભાગ બદલી શકે છે?

ફોરવર્ડ પ્રોક્સી વિસ્તારતી વખતે વિનંતી URL ની પસંદગીને પ્રતિસાદ અનુકૂલન અને TLS ડિક્રિપ્શનથી અલગ રાખો.

url_rewrite_program વિનંતી URL ના નિર્ણયો પર કામ કરે છે. તે વિનંતીની માહિતી મેળવે છે અને Squid ના સહાયક પ્રોટોકોલ દ્વારા જવાબ આપે છે; તે ડાઉનલોડ થયેલ ફાઇલ મેળવીને સંપાદિત કરી પાછી મોકલતું નથી.

ઇચ્છિત ક્રિયાસંબંધિત સીમા
બ્રાઉઝરને રીડાયરેક્ટ કરવું અથવા બીજી વિનંતી URL પસંદ કરવીવિનંતી તબક્કે URL ફરીથી લખનાર સહાયકની ભૂમિકા
દેખાતા HTTP પ્રતિસાદના મુખ્ય ભાગને બદલવોપ્રતિસાદ અનુકૂલનનું સાધન, જેમ કે રૂપરેખાંકિત ICAP પ્રતિસાદ ફેરફાર
સામાન્ય CONNECT ની અંદર HTTP વાંચવુંલક્ષ્યનું TLS પહેલાં યોગ્ય ડિપ્લોયમેન્ટ ગોઠવણી હેઠળ સમાપ્ત કરવું પડશે
એપ્લિકેશન દ્વારા એન્ક્રિપ્ટ થયેલ ફાઇલ ડિક્રિપ્ટ કરવીફાઇલનું ફોર્મેટ, અલ્ગોરિધમ અને કી, તે કેવી રીતે પરિવહન થાય તેને ધ્યાનમાં લીધા વિના

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

સામાન્ય CONNECT એન્ક્રિપ્ટ થયેલા ટનલ બાઇટ્સ મોકલે છે. URL સહાયક અંદરનો પ્રતિસાદ ખુલ્લો કરતું નથી; નિરીક્ષણની જરૂર હોય તેવી રચનાએ નક્કી કરવું પડે કે આ ટ્રાફિક ડિપ્લોયમેન્ટમાં ડિક્રિપ્ટ કરી શકાય છે અને કરવો જોઈએ કે નહીં.

જ્યાં Squid HTTP સંદેશનું નિરીક્ષણ કરી શકે છે, ત્યાં પ્રતિસાદ ફેરફાર સેવા હજી પણ સામગ્રી એન્કોડિંગ, બદલાયેલી લંબાઈ અને નિષ્ફળતાના વર્તનની જવાબદારી ધરાવે છે. રૂપાંતરણ વ્યાખ્યાયિત કર્યા પછી ઇન્ટરફેસ પસંદ કરો, કામ કરતા URL ફરીથી લખવાના ઉદાહરણને એવા પ્રોસેસિંગ તબક્કા સુધી લંબાવવાને બદલે જે તેને ક્યારેય મળતું નથી.

સંબંધિત લેખો