વેબ-ફોર્મ પ્રોક્સીઓ બ્રાઉઝરનું મૂળ બદલે છે, ફક્ત એક્ઝિટ IP નહીં
URL-એન્ટ્રી પ્રોક્સી વેબસાઇટને નેટિવ બ્રાઉઝર પ્રોક્સીથી અલગ પાડો અને સમજાવો કે જટિલ લોગિન અને સ્ક્રિપ્ટો અલગ રીતે કેમ વર્તી શકે.
URL બોક્સ ધરાવતું પૃષ્ઠ એ વેબ એપ્લિકેશન છે. ત્યાં ગંતવ્ય દાખલ કરવાથી તે એપ્લિકેશનને સામગ્રી લાવીને બતાવવા કહેવાય છે. બ્રાઉઝરને HTTP કે SOCKS પ્રોક્સી વાપરવા કહેવાથી આ અલગ ગોઠવણ છે.
નેટિવ પ્રોક્સી સેટિંગમાં બ્રાઉઝર ગંતવ્યના URLને હજી પણ વેબસાઇટ ગણે છે. પરંપરાગત વેબ-ફોર્મ પ્રોક્સીમાં દેખાતું પૃષ્ઠ પ્રોક્સી એપ્લિકેશનની પોતાની URL યોજના અને મૂળ દ્વારા આપવામાં આવે છે. સેવા નેવિગેશન ચાલુ રહે તે માટે લિંક, સ્ક્રિપ્ટ, હેડર કે કૂકીઝ ફરી લખી શકે છે.
| વર્તન | તફાવત કેમ મહત્વનો છે |
|---|---|
| સમાન-મૂળ તપાસ | બ્રાઉઝર ખરેખર લોડ કરેલા મૂળનું મૂલ્યાંકન કરે છે |
| કૂકીઝ અને રીડાયરેક્ટ | ડોમેન, પાથ અને સુરક્ષિત સંદર્ભનું વર્તન દર્શાવેલ URL સાથે મેળ ખાવું જોઈએ |
| નવા URL બનાવતી સ્ક્રિપ્ટો | વિનંતીઓ સાદી લિંક-પુનર્લેખન યોજનામાંથી છટકી શકે છે |
| સ્થાયી જોડાણો કે WebSockets | પ્રોક્સી એપ્લિકેશનને સ્પષ્ટ સુસંગત હેન્ડલિંગની જરૂર છે |
આ એક જાણીતું પરિણામ સમજાવે છે: સાદો લેખ લોડ થાય છે, પણ દસ્તાવેજ એડિટર કે લોગિન પ્રવાહ નિષ્ફળ જાય છે. નિષ્ફળતાનો અર્થ એ નથી કે ગંતવ્ય સેવાના એક્ઝિટ IPને નકારે છે. મધ્યસ્થ URL અને બ્રાઉઝર સુરક્ષા વિશેની એપ્લિકેશનની ધારણાઓ જાળવી ન શકે.
TLS ક્યાં પૂરું થાય તે પણ અલગ પાડો. ગંતવ્યની સામગ્રી લાવીને ફરી પ્રકાશિત કરતી સેવા એન્ક્રિપ્ટેડ સત્ર વહન કરતા સામાન્ય CONNECT રિલે કરતાં અલગ વિશ્વાસ સ્થિતિમાં છે. પ્રોક્સી સાઇટના પોતાના સરનામે HTTPS જોવાથી બ્રાઉઝરથી મૂળ સાઇટ સુધી એન્ડ-ટુ-એન્ડ TLS જોડાણ સાબિત થતું નથી.
જો ધ્યેય બીજા એક્ઝિટ દ્વારા સામાન્ય બ્રાઉઝિંગ છે, તો તમારી સેવા અથવા પ્રોક્સી સૂચિમાંથી HTTP કે SOCKS એન્ડપોઇન્ટ પસંદ કરો અને સમર્થિત નેટિવ પ્રોક્સી રૂપરેખાંકન વાપરો, જેમ કે Firefox ના કનેક્શન સેટિંગ્સ. આ સામાન્ય રીતે બ્રાઉઝરના સામાન્ય ગંતવ્ય અર્થઘટનનો વધુ ભાગ જાળવી રાખે છે. URL-એન્ટ્રી સાઇટ જાણી જોઈને પસંદ કરેલી એપ્લિકેશન હોઈ શકે, પણ ઓછા સેટઅપ સાથે એ જ ઇન્ટરફેસ તરીકે રજૂ ન કરવી જોઈએ.