Ձևի նպատակակետը պահեք հարցման մեջ, իսկ պրոքսին՝ միացման կարգավորումներում։ Պրոքսին չի պահանջում հատուկ ձևային դաշտ ձեր ուզած URL-ով, եթե չեք օգտագործում կոնկրետ կայքի վեբ-պրոքսի ինտերֆեյսը։

Ruby-ի Net::HTTP-ի համար բացահայտ HTTP պրոքսի կարելի է տրամադրել հաճախորդը ստեղծելիս․

require 'net/http'

uri = URI('https://example.com/form')
http = Net::HTTP.new(uri.hostname, uri.port,
                     '203.0.113.10', 8080)
http.use_ssl = true
http.open_timeout = 5
http.read_timeout = 10
request = Net::HTTP::Post.new(uri.request_uri)
request.set_form_data('message' => 'hello')
response = http.start { |session| session.request(request) }

Պրոքսին օրինակ է միայն․ թույլատրված հանրային ձևերի փորձարկումների HTTP թեկնածուները հասանելի են HTTP պրոքսիների ցանկում։ Ձևի վերջնակետը պետք է փոխարինվի ուղարկումն ընդունելու համար նախատեսված ծառայությամբ։ Net::HTTP-ի պրոքսի փաստաթղթերը նույնպես նկարագրում են պրոքսիի հավատարմագրերը և միջավայրից ստացված պրոքսիի կարգավորումները։

Կարդացեք պատասխանը նախքան պրոքսիին մեղադրելը

Ձևը մերժող սերվերը կարող է HTTP սխալ տալ այն բանից հետո, երբ պրոքսիի ուղին ճիշտ աշխատել է։ Ստուգեք պատասխանի կարգավիճակը և նպատակակետի պահանջները․ մեթոդ, բովանդակության տեսակ, ձևի դաշտեր, քուքիներ և ցանկացած հարցման նշան։

Պրոքսիի նույնականացման մարտահրավերը գալիս է պրոքսիից։ Հավելված մուտքը կամ մերժված ձևը պատկանում են նպատակակետին։ Պահեք նրանց հավատարմագրերը առանձին։ Նպատակակետի գաղտնաբառը պրոքսիի կարգավորումներում ավելացնելը չի կարող բավարարել նպատակակետի մուտքը։

Squid-ի փոխանցման վերնագրերի կանոնները ևս մեկ հնարավոր շփոթության աղբյուր են։ Նրանց սերվերային քաղաքականությունը առանձին է վավեր Ruby POST կառուցելուց։ Մի փոխեք ընդհանուր պրոքսիի վերնագրերի կանոնները միայն այն պատճառով, որ ձևը մեկ անգամ ձախողվել է։

Կրկնվող փորձերի համար հաշվի առեք, որ առաջին ուղարկումը կարող է արդեն մշակված լինել։ Կորցրած պատասխանը ապացույց չէ, որ POST-ը երբեք չի հասել հավելվածին։

Առնչվող հոդվածներ