POST 대신 id 리디렉션에서 GET을 사용하는 HttpWebRequest

Question

영어로 죄송합니다.

델파이에서는 hoWaitForUnexpectedData 옵션이 활성화 된 idHttp 구성 요소가 있습니다.

URL에 POST 요청을 보내면 동일한 POST 요청 및 헤더를 가진 두 번째 URL로 클라이언트가 리디렉션됩니다. 또한 서버 응답에는 헤더에 "연결 : 연결 유지"가 포함됩니다.

그러나 HttpWebRequest 구성 요소를 사용하여 C#에서 동일한 요청을 시도하면 GET 메서드를 사용하여 두 번째 URL로 리디렉션됩니다.

델파이 idHTTP처럼 작동하려면 C# HttpWebRequest 구성 요소가 필요합니다. 리디렉션을 따르는 경우 왜 POST 대신 GET을 사용하는지 이해할 수 없습니다. 표준에서 정의하는 GET을 사용

// The server is supposed to send a 'Content-Length' header without sending 
    // the actual data. 1xx, 204, and 304 replies are not supposed to contain 
    // entity bodies, either... 
    if TextIsSame(ARequest.Method, Id_HTTPMethodHead) or 
    TextIsSame(ARequest.MethodOverride, Id_HTTPMethodHead) or 
    ((AResponse.ResponseCode div 100) = 1) or 
    (AResponse.ResponseCode = 204) or 
    (AResponse.ResponseCode = 304) then 
    begin 
    // Have noticed one case where a non-conforming server did send an 
    // entity body in response to a HEAD request. If requested, ignore 
    // anything the server may send by accident 
    if not (hoWaitForUnexpectedData in FOptions) then begin 
     Exit; 
    end; 
    Result := CheckForPendingData(100); 
    end 
    else if (AResponse.ResponseCode div 100) = 3 then 
    begin 
    // This is a workaround for buggy HTTP 1.1 servers which 
    // does not return any body with 302 response code 
    Result := CheckForPendingData(5000); 
    end else begin 
    Result := True; 
    end; 

Answer 1

는 HTTP 리디렉션을 처리해야합니다

여기 hoWaitForUnexpectedData를 사용하여 델파이 내 코드입니다. 따라서 POST를 보내고 응답으로 리디렉션을받는 경우 예상되는 동작은 리디렉션 주소로 GET을 수행하는 것입니다. 이전 Delphi 구성 요소가 이전 사례를 따르고 POST 동사를 포함하여 호출을 복제한다고 의심됩니다.

HttpWebRequest 개체에서 AllowAutoRedirect을 사용하지 않도록 설정하고 수동으로 처리하려고합니다. 사례가 표준과 다를 것 같습니다.

Answer 2

hoWaitForUnexpectedData 옵션은 TIdHTTP이 리디렉션을 처리하는 방법에 영향을 미치지 않으며 인용 한 코드 섹션도 영향을 미치지 않습니다.

그러나 hoTreat302Like303 옵션은 리디렉션 처리에 영향을 미칩니다. TIdHTTP이 리디렉션을 받거나 hoTreat302Like303을 사용하여 302 리디렉션을 수신하면 TIdHTTP은 GET으로 새 요청을 보냅니다. 그렇지 않으면, 리디렉션 된 요청과 동일한 동사를 사용하여 새 요청을 전송합니다. 이것은 의도적으로 설계된 동작입니다,이 행동 뒤에 합리적인를 설명하는 TIdHTTPProtocol.ProcessResponse() 방법의 구현 코드에 주석의 시리즈가하십시오에 대한 GET을 보낼 수

이

// GDG 21/11/2003. If it's a 303, we should do a get this time 

    // RLebeau 7/15/2004 - do a GET on 302 as well, as mentioned in RFC 2616 

    // RLebeau 1/11/2008 - turns out both situations are WRONG! RFCs 2068 and 
    // 2616 specifically state that changing the method to GET in response 
    // to 302 and 303 is errorneous. Indy 9 did it right by reusing the 
    // original method and source again and only changing the URL, so lets 
    // revert back to that same behavior! 

    // RLebeau 12/28/2012 - one more time. RFCs 2068 and 2616 actually say that 
    // changing the method in response to 302 is erroneous, but changing the 
    // method to GET in response to 303 is intentional and why 303 was introduced 
    // in the first place. Erroneous clients treat 302 as 303, though. Now 
    // encountering servers that actually expect this 303 behavior, so we have 
    // to enable it again! Adding an optional HTTPOption flag so clients can 
    // enable the erroneous 302 behavior if they really need it. 

그것의 JIST는 HTTP 사양 말하는 것을는 303 리디렉션하는 반면, 302은 GET을 보낼지 여부가 모호합니다. 일부 브라우저는 그렇지 않으며 일부 브라우저는 그렇지 않습니다. 이것이 이전 Indy 버전과의 하위 호환성을 위해 기본적으로 비활성화되어 있지만 hoTreat302Like303 옵션이 추가 된 이유입니다.

따라서 설명하는 동작은 hoTreat302Like303 (기본값) 인 302 리디렉션이 발생해야 함을 의미합니다. 이 옵션을 사용하면 TIdHTTP은 HttpWebRequest처럼 작동합니다.