પરંપરાગત Whois તેની પોતાની TCP પ્રોટોકોલ વાપરે છે, સામાન્ય રીતે પોર્ટ 43 પર. જવાબ ઇન્ટરનેટ ડોમેન વર્ણવે છે એટલા માટે જ તે HTTP વિનંતી નથી.

http_proxy ચલ ફક્ત એ સોફ્ટવેરને મદદ કરે છે જે તેને સમર્થિત HTTP પ્રોક્સી માર્ગ માટે વાંચે છે. Whois અમલીકરણ પોતાનું સામાન્ય TCP જોડાણ કરતી વખતે તે ચલને અવગણી શકે છે.

જો કોઈ ચોક્કસ ક્લાયન્ટ SOCKS ને સમર્થન આપે છે, તો તે દસ્તાવેજીકૃત સુવિધા ગોઠવો. સુસંગત TCP રેપર બીજો વિકલ્પ છે, જે રેપરની અટકાવ મર્યાદાઓ અને પ્રોક્સીની લક્ષ્ય-પોર્ટ નીતિને આધીન છે. એવું ન ધારો કે whois નામનાં દરેક પ્રોગ્રામમાં સમાન સુવિધાઓ છે. જો તે ક્લાયન્ટ SOCKS ને સમર્થન આપે છે અને જાહેર મધ્યસ્થીઓને મંજૂરી હોય, તો SOCKS પ્રોક્સી યાદી વાસ્તવિક Whois સર્વરો અને પોર્ટ, જેમાં રેફરલ્સનો સમાવેશ થાય છે, તેમાં પ્રવેશ ચકાસવા માટે ઉમેદવારો આપે છે.

HTTP-આધારિત નોંધણી-માહિતી સેવાઓ, જેમાં RDAP પણ છે, અલગ એપ્લિકેશન પ્રોટોકોલ વાપરે છે અને HTTP-જાણકાર ક્લાયન્ટનું પ્રોક્સી સમર્થન મેળવી શકે છે. ઇન્ટરફેસ બદલવો એ સાધન અને જવાબ ફોર્મેટનો જાણી જોઈને કરાયેલો ફેરફાર છે, એ સાબિતી નથી કે મૂળ Whois પ્રશ્ન હંમેશા HTTP હતો.

રેફરલ વર્તન પણ ધ્યાનમાં રાખો: એક શોધ એક કરતાં વધુ સર્વરનો સંપર્ક કરી શકે છે. એક મંજૂર જોડાણ સાબિત કરતું નથી કે પછીનું દરેક લક્ષ્ય ઇચ્છિત માર્ગ વાપરી શકે છે.

સંબંધિત લેખો