Waarom APT nie CONNECT vir elke aflaai gebruik nie
Gewone HTTP-deurgee en HTTPS-tonnelering gebruik verskillende proxy-gesprekke. 'n Diens wat net CONNECT ondersteun, ondersteun dalk nie die versoeke wat 'n HTTP-bewaarplek lewer nie.
“Die proxy aanvaar CONNECT” beteken nie dat dit elke versoek wat APT sal stuur, aanvaar nie.
Vir 'n gewone HTTP-bewaarplek kan APT normale HTTP-proxy-deurgee gebruik: die proxy ontvang 'n HTTP-versoek wat die bestemmingsbron identifiseer. Vir HTTPS deur 'n HTTP-proxy vestig die kliënt gewoonlik 'n CONNECT-tonnel en onderhandel dan die bestemming se TLS-sessie daardeur.
| Bestemming | Tipiese gesprek met 'n HTTP-proxy |
|---|---|
| HTTP-bewaarplek | Stuur 'n HTTP-versoek deur |
| HTTPS-bewaarplek | CONNECT, dan die bestemming se TLS |
'n Diens wat net tonnels aanvaar, kan 'n gewone deurgegee versoek verwerp. 'n HTTP 405 verdien 'n blik op die werklike metode, die antwoordverskaffer en die proxybeleid; dit bewys nie dat APT nie SOCKS ondersteun nie of dat sy wagwoord verkeerd is nie.
Vergelyk die diens se ondersteunde gedrag met die APT-vervoerdokumentasie en CONNECT-semantiek. Gebruik 'n versoenbare goedgekeurde diens of 'n ondersteunde bewaarplek-URL. Vir openbare bewaarplekke waar openbare tussengangers toegelaat word, bied die HTTP-proxylys kandidate om teen daardie vereistes te toets. Moenie aanneem dat die byvoeging van https:// by die proxy-adres die bewaarplek se protokol verander of elke versoek in 'n tonnel omskep nie.