Zergatik gorde dezaketen nabigatzaileek Squid-en HTTPS blokeo-orria
Ulertu zergatik erakuts dezakeen nabigatzaileak bere tunel-errorea CONNECT eskaera ukaturako itzulitako HTML pertsonalizatuaren ordez.
Proxyaren blokeo-orri pertsonalizatua HTTP gune batentzat agertzen da. HTTPS gune baterako, nabigatzaileak tunel-errore bat erakusten du horren ordez. HTML txantiloia berriro ordezkatzeak ezer alda dezake.
HTTP proxy esplizitu batekin, HTTPS bisita bat CONNECT-ekin hasten da normalean. Nabigatzaileak proxari ostalari eta portu baterako tunel bat irekitzeko eskatzen dio. Squid-ek eskaera hori ukatzen badu, gunearen TLS saioa ez da inoiz hasten.
Ukapenak HTTP egoera eta erantzun-edukia izan ditzake. CONNECT erantzun huts egindako hori curl-ekin azter dezakezu nabigatzailearen errore-orritik independenteki. Horrek ez du eskatzen nabigatzaileak emandako HTMLa helmugaren web-orri gisa aurkeztea. Nabigatzaileak CONNECT errorearen gorputza baztertu eta bere proxy errore-interfazea erabil dezake; aurkezpen zehatza bezeroaren araberakoa da.
Squid-en ukapenak jada aurreikusitako deny_info gorputza badu, haren testua, estilo-orria edo fitxategi-baimenak editatzeak ez du aldatzen nabigatzaileak zein erantzun-fase kudeatzen duen. Mantendu ukapenaren egoera eta sarbide-erregistroa eskuragarri CONNECT ukatua izan zen eta zergatik zehazteko. Nabigatzailearen orri generiko batek politika-xehetasunak ezkuta ditzake proxyak araua behar bezala betearazten duen bitartean.
Blokeo-orri bat HTTPS konexio atzematean zerbitzatzea beste arkitektura bat da, TLS amaitzea, bezeroaren konfiantza eta ziurtagirien kudeaketa dakarrena. Ez da deny_info editatuz gaitzen, eta txantiloi pertsonalizatuak ez du blokeatutako gunea ordezkatzeko agintaritzarik ematen. Aukeratu diseinu hori beharrezkoa bada soilik; bestela, erabili bezeroaren eskuragarri dagoen errore-txostena eta proxyaren eragiketa-erregistroak.