مقصد فرم را در درخواست و پروکسی را در پیکربندی اتصال نگه دارید. پروکسی به فیلد ویژه‌ای در فرم که URL موردنظر شما را داشته باشد نیاز ندارد، مگر اینکه از رابط وب‌پروکسی یک وب‌سایت خاص استفاده کنید.

برای 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 منبع احتمالی دیگری برای سردرگمی است. سیاست سمت سرور آن‌ها جدا از ساخت یک POST معتبر روبی است. صرفاً به این دلیل که فرم یک بار شکست خورده، قواعد سرآیند یک پروکسی مشترک را تغییر ندهید.

برای تلاش‌های دوباره، در نظر بگیرید که شاید ارسال نخست پیش‌تر پردازش شده باشد. پاسخ گم‌شده اثبات این نیست که POST هرگز به برنامه نرسیده است.

مقالات مرتبط