Aasynchronous WinHTTP
저장소/VC++출처 : MSDN Magazine
http://msdn.microsoft.com/ko-kr/magazine/cc716528.aspx
WinHttpSetStatusCallback
http://msdn.microsoft.com/en-us/library/aa384115(v=vs.85).aspx
WinHttpCloseHandle
http://msdn.microsoft.com/en-us/library/aa384090(v=vs.85).aspx
참 잘 긁어지네 ㅎㅎ
비동기 WinHTTP
Kenny Kerr
분산 프로그래밍의 발전으로 최신 Windows® 기반 응용 프로그램에서는 HTTP 요청이 가능하게 되었습니다. HTTP가 비교적 간단하기는 하지만 오늘날 요구되는 HTTP 작업은 그렇게 간단하지만은 않습니다. 비동기 처리를 위해서는 크기가 커질 수도 있는 요청 및 응답의 버퍼링, 인증, 자동 프록시 서버 검색, 영구적 연결 등이 필요합니다. 물론 이러한 문제 중 많은 부분을 무시할 수도 있지만 응용 프로그램의 품질이 저하됩니다. 게다가 HTTP는 TCP 소켓으로 모방할 만큼 간단하지도 않습니다. 그렇다면 과연 C++ 개발자는 이러한 과제를 어떻게 해결해야 할까요?
많은 개발자들이 오해하고 있는 사실 중 하나가 바로 응용 프로그램에서 웹에 액세스하도록 하려면 Microsoft® .NET Framework를 사용해야 한다는 것입니다. 사실을 말하자면 관리되는 코드를 사용하는 개발자는 위에서 언급한 문제를 해결해야 하지만 REST(Representational State Transfer) 같은 웹 서비스의 새로운 스타일은 네이티브 코드를 사용한 프로그래밍만큼 쉽습니다.
이번 달 칼럼에서는 HTTP 클라이언트 구현에 사용되는 API인 WinHTTP(Windows HTTP 서비스)의 사용 방법을 설명하겠습니다. Windows Vista®와 Windows Server® 2008의 경우 4GB를 초과하는 파일의 업로드 지원, 향상된 인증서 기반 인증, 원본 및 대상 IP 주소 검색 등 많은 기능이 WinHTTP에 추가되었습니다.
WinHTTP는 C API는 물론 COM API까지 제공합니다. C API는 그 특성상 처음에는 사용하기가 다소 어렵지만 C++의 도움을 약간만 받으면 HTTP 클라이언트 구축에 사용할 수 있는 매우 강력하고 유연한 API를 얻을 수 있습니다. 또한 동기 프로그래밍 모델과 비동기 프로그래밍 모델을 모두 제공합니다. 여기서는 다음과 같은 이유로 비동기 모델을 중점적으로 다룹니다. 첫째, 동시성이 보편화된 오늘날의 환경에서는 병렬 프로그래밍이 중요합니다. 둘째, 대부분의 설명서와 교육 과정이 단일 스레드 프로그래밍에 너무 치중되었기 때문에 병렬 프로그래밍을 거의 다루지 않고 있습니다. 조금씩 다루고 있는 기본적인 지침도 너무 간단하게 설명되어 실제 프로그래밍에는 도움이 안 되는 경우가 많습니다. 때문에 병렬 프로그래밍을 어렵게 생각하는 개발자가 많지만 매우 체계적이고 나름대로 재미도 있다는 사실을 곧 알게 될 겁니다. (뭐, 재미의 기준은 사람마다 다를 수 있겠지만 꺼려할 필요는 없다는 말입니다.)
WinHTTP 개요
C API의 경우 확실히 드러나지는 않지만 WinHTTP API는 논리적으로 세션, 연결, 요청이라는 세 가지 개별 개체로 모델링되어 있습니다. 그 중 세션 개체는 WinHTTP를 초기화하는 데 필요합니다. 세션은 응용 프로그램마다 하나만 필요하며 연결 개체를 만드는 데 사용됩니다. 연결 개체는 통신할 HTTP 서버마다 하나씩 필요하고 개별 요청 개체를 만들 수 있도록 해줍니다. 실제 네트워크 연결은 처음으로 요청을 보낼 때 설정됩니다. 그림 1은 이러한 개체 간의 관계를 보여 줍니다. 세션에 활성 연결이 여러 개 있을 수 있고 연결에는 동시 요청이 여러 개 있을 수 있습니다.
.gif)
그림 1 세션, 연결 및 요청(더 크게 보려면 이미지를 클릭하십시오.)
세션, 연결 및 요청 개체는 HINTERNET 핸들로 표현됩니다. 개체를 만드는 데 사용되는 함수는 서로 다르지만 소멸시킬 때는 모두 WinHttpCloseHandle 함수로 해당 핸들을 전달하는 방법이 사용됩니다. 또한 WinHttpQueryOption나 WinHttpSetOption 같은 함수는 핸들을 사용하여 WinHTTP 개체에서 지원되는 다양한 옵션을 쿼리하고 설정합니다.
그림 2에는 세 가지 WinHTTP 핸들의 수명 주기를 관리하고 핸들에 대한 옵션을 쿼리 및 설정하는 데 사용할 수 있는 WinHttpHandle 클래스가 나와 있습니다. 따라서 요청 개체가 있다면 WINHTTP_OPTION_URL 옵션을 사용하여 해당 개체의 전체 URL을 검색할 수 있습니다.
그림 2 WinHttpHandle 클래스
DWORD length = 0; request.QueryOption(WINHTTP_OPTION_URL, 0, length); ASSERT(ERROR_INSUFFICIENT_BUFFER == ::GetLastError()); CString url; COM_VERIFY(request.QueryOption(WINHTTP_OPTION_URL, url.GetBufferSetLength(length / sizeof(WCHAR)), length)); url.ReleaseBuffer();
그림 2 WinHttpHandle 클래스class WinHttpHandle
{
public:
WinHttpHandle() :
m_handle(0)
{}
~WinHttpHandle()
{
Close();
}
bool Attach(HINTERNET handle)
{
ASSERT(0 == m_h);
m_handle = handle;
return 0 != m_handle;
}
HINTERNET Detach()
{
HANDLE handle = m_handle;
m_handle = 0;
return handle;
}
void Close()
{
if (0 != m_handle)
{
VERIFY(::WinHttpCloseHandle(m_handle));
m_handle = 0;
}
}
HRESULT SetOption(DWORD option,
const void* value,
DWORD length)
{
if (!::WinHttpSetOption(m_handle,
option,
const_cast<void*>(value),
length))
{
return HRESULT_FROM_WIN32(::GetLastError());
}
return S_OK;
}
HRESULT QueryOption(DWORD option,
void* value,
DWORD& length) const
{
if (!::WinHttpQueryOption(m_handle,
option,
value,
&length))
{
return HRESULT_FROM_WIN32(::GetLastError());
}
return S_OK;
}
HINTERNET m_handle;
};
필자의 코드 조각에서는 COM_VERIFY 매크로를 사용하여 함수에서 검사가 필요한 HRESULT를 반환하는 지점을 명확하게 확인합니다. 이 부분은 예외를 발생시키거나 직접 HRESULT를 반환하는 등의 적절한 오류 처리로 대체할 수 있습니다.
세션 개체
세션 개체는 WinHttpOpen 함수를 사용하여 만듭니다. 첫 번째 매개 변수는 응용 프로그램의 선택적 에이전트 문자열을 지정합니다. 다음 세 매개 변수는 WinHTTP에서 서버 이름을 확인하는 방식을 지정하는데, 서버에 직접 액세스할지, 프록시 서버를 통해 액세스할지를 제어하는 데 유용합니다(아래 "프록시 설정 결정" 참조). 마지막 매개 변수에는 플래그가 포함되어 있습니다. 예제에는 현재 하나만 정의되어 있습니다. WINHTTP_FLAG_ASYNC는 WinHTTP 함수가 비동기로 작동해야 함을 나타냅니다.
HINTERNET session = ::WinHttpOpen(0, // no agent string
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS,
WINHTTP_FLAG_ASYNC);
그림 3에는 그림 2의 WinHttpHandle 클래스에서 파생되고 세션 개체의 생성 과정을 단순화해 주는 WinHttpSession 클래스가 나와 있습니다. WinHttpSession은 대분의 경우에 그대로 적용할 수 있는 기본값을 사용하여 세션을 만듭니다. 그림 3 WinHttpSession 클래스
그림 3 WinHttpSession 클래스class WinHttpSession : public WinHttpHandle
{
public:
HRESULT Initialize()
{
if (!Attach(::WinHttpOpen(0, // no agent string
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS,
WINHTTP_FLAG_ASYNC)))
{
return HRESULT_FROM_WIN32(::GetLastError());
}
return S_OK;
}
};
연결 개체
연결 개체는 WinHttpConnect 함수를 사용하여 만듭니다. 첫 번째 매개 변수는 새 연결이 속할 세션을 지정하고, 다음 매개 변수에는 서버의 이름 또는 IP 주소가 나열됩니다. 세 번째 매개 변수는 서버의 포트 번호를 지정하는데, INTERNET_DEFAULT_PORT를 대신 사용할 수 있습니다. INTERNET_DEFAULT_PORT를 사용하는 경우 WinHTTP는 일반 HTTP 요청에 포트 80을 사용하고 보안 HTTP 요청(HTTPS)에 포트 443을 사용합니다.
HINTERNET connection = ::WinHttpConnect(session,
L"example.com",
INTERNET_DEFAULT_PORT,
0); // reserved
if (0 == connection)
{
// Call GetLastError for error information
}
그림 4의 코드는 마찬가지로 WinHttpHandle에서 파생되고 연결 개체의 생성 과정을 단순화하는 WinHttpConnection 클래스를 보여 줍니다.
그림 4 WinHttpConnection 클래스
그림 4 WinHttpConnection 클래스class WinHttpConnection : public WinHttpHandle
{
public:
HRESULT Initialize(PCWSTR serverName,
INTERNET_PORT portNumber,
const WinHttpSession& session)
{
if (!Attach(::WinHttpConnect(session.m_handle,
serverName,
portNumber,
0))) // reserved
{
return HRESULT_FROM_WIN32(::GetLastError());
}
return S_OK;
}
};
요청 개체
요청 개체부터가 흥미로운 부분입니다. 요청 개체는 WinHttpOpenRequest 함수를 사용하여 만듭니다.
HINTERNET request = ::WinHttpOpenRequest(connection,
0, // use GET as the verb
L"/developers/",
0, // use HTTP version 1.1
WINHTTP_NO_REFERRER,
WINHTTP_DEFAULT_ACCEPT_TYPES,
0); // flags
첫 번째 매개 변수는 요청이 속할 연결을 지정하고, 두 번째 매개 변수는 요청에 사용할 HTTP 동사를 지정합니다. 이 두 번째 매개 변수가 0이면 GET 요청으로 간주됩니다. 세 번째 매개 변수는 요청된 리소스의 이름 또는 상대 경로를 지정합니다. 네 번째 매개 변수는 사용할 HTTP 프로토콜 버전을 지정합니다. 이 매개 변수가 0이면 HTTP 버전 1.1로 간주됩니다. 다섯 번째 매개 변수는 참조 URL을 지정합니다. 이 매개 변수는 보통 WINHTTP_NO_REFERRER로 지정되는데 이는 참조자를 나타냅니다. 마지막에서 두 번째 매개 변수는 클라이언트에서 허용되는 미디어 유형을 지정합니다. 이 매개 변수가 WINHTTP_DEFAULT_ACCEPT_TYPES이면 유형이 지정되지 않습니다. 이 경우 보통 서버는 클라이언트에서 텍스트 응답만 허용되는 것으로 간주합니다. 마지막 매개 변수는 요청의 동작을 제어하는 데 사용할 수 있는 플래그를 지정합니다. 예를 들어 SSL 요청을 만들려면 WINHTTP_FLAG_SECURE 플래그를 지정할 수 있습니다.
여기에서 동기 프로그래밍 모델과 비동기 프로그래밍 모델이 차이를 보입니다. 동기 모델의 경우 요청을 보내는 함수를 호출한 다음 응답이 수신될 때까지 차단하는 함수를 호출하지만, 비동기 모델의 경우에는 콜백 함수를 사용하기 때문에 나머지 함수 호출이 비동기적으로 작동하고 호출 스레드가 차단되지 않습니다.
콜백 함수는 WinHttpSetStatusCallback 함수를 사용하여 요청 개체와 연결됩니다.
if(WINHTTP_INVALID_STATUS_CALLBACK==::WinHttpSetStatusCallback(request,
Callback, WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS,
0)) // reserved
{
// Call GetLastError for error information
}
첫 번째 WinHttpSetStatusCallback 매개 변수는 진행률을 알릴 요청을 지정하고, 두 번째 매개 변수는 콜백 함수의 주소를 지정합니다. 세 번째 매개 변수는 수신할 알림을 지정합니다. WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS는 표시 가능한 모든 알림이 포함된 비트 마스크입니다.
이 콜백 함수는 다음과 같이 프로토타입화되어야 합니다.
void CALLBACK Callback(HINTERNET handle,
DWORD_PTR context,
DWORD code,
void* info,
DWORD length);
첫 번째 매개 변수는 콜백과 관련한 개체의 핸들을 제공합니다. 물론 세션 개체와 연결 개체의 알림을 처리하는 콜백을 만들 수도 있지만 이러한 콜백은 요청 개체와 거의 동일합니다. 두 번째 매개 변수는 요청을 보낼 때 요청에 연결되는 응용 프로그램 정의 값입니다. 세 번째 매개 변수는 콜백 이유를 나타내는 코드를 제공합니다. 마지막 매개 변수 2개는 이전 매개 변수에 의해 제공되는 코드에 따라 추가 정보가 포함될 수 있는 버퍼를 지정합니다. 예를 들어 WINHTTP_CALLBACK_STATUS_REQUEST_ERROR 알림 코드가 수신된 경우 info 매개 변수는 WINHTTP_ASYNC_RESULT 구조를 가리킵니다.
요청은 WinHttpSendRequest 함수를 사용하여 전송됩니다.
if (!::WinHttpSendRequest(request,
WINHTTP_NO_ADDITIONAL_HEADERS,
0, // headers length
WINHTTP_NO_REQUEST_DATA,
0, // request data length
0, // total length
0)) // context
{
// Call GetLastError for error information
}
첫 번째 매개 변수는 전송할 요청을 나타냅니다. 두 번째와 세 번째 매개 변수는 요청에 포함할 추가 헤더가 있는 문자열을 지정합니다. 이 매개 변수를 WINHTTP_NO_ADDITIONAL_HEADERS로 지정하면 처음에 추가 헤더가 포함되지 않습니다. 이 매개 변수를 사용하는 대신 WinHttpAddRequestHeaders 함수를 사용하여 요청을 전송하기 전에 헤더를 추가할 수도 있습니다. 네 번째와 다섯 번째 매개 변수는 요청의 내용 또는 본문으로 포함할 데이터가 들어 있는 선택적 버퍼를 지정합니다. 이 매개 변수는 POST 요청에 많이 사용됩니다. 마지막에서 두 번째 매개 변수는 요청 내용의 총 길이를 지정합니다. 이 값은 요청에 포함되는 Content-Length 헤더를 만드는 데 사용됩니다. 이 값이 이전 매개 변수에 의해 제공되는 데이터의 길이를 초과하면 요청을 완성하기 위해 WinHttpWriteData 함수를 사용하여 추가 데이터가 작성될 수 있습니다.
여기서는 비동기 프로그래밍 모델을 사용하고 있으므로 이 함수는 요청이 전송되기를 기다리지 않고 결과를 반환하고, WinHTTP가 WinHttpSendRequest에 대한 마지막 매개 변수에 지정된 컨텍스트 값을 전달하는 콜백 함수를 통해 상태 업데이트를 제공합니다.
여기서 잠시 C++를 사용하여 지금까지 설명한 내용을 하나로 결합하는 방법을 살펴보겠습니다. 이전 섹션에서는 간단한 WinHttpSession 및 WinHttpConnection 클래스를 사용해 세션과 연결을 모델링해보았습니다. 그런데 다양한 요청 관련 함수 호출을 래핑하는 것은 물론, 응용 프로그램에 필요한 특정 요청 유형을 간단히 작성하기 위해서는 WinHttpRequest 클래스가 필요합니다. 이 클래스의 기능에는 전송되는 요청 데이터와 응답 데이터를 모두 저장할 버퍼를 효과적으로 관리하는 것도 포함됩니다. 그림 5는 이 기사의 나머지 부분에서 사용할 WinHttpRequest 클래스 템플릿을 대략적으로 보여 줍니다. 흥미로운 논리는 OnCallback 멤버 함수 내에서 많이 실행됩니다. 그러나 먼저 WinHttpRequest 클래스 템플릿이 어떻게 디자인되었는지를 설명하고 넘어가겠습니다. 그림 5 WinHttpRequest 클래스 템플릿
그림 5 WinHttpRequest 클래스 템플릿template <typename T>
class WinHttpRequest : public WinHttpHandle
{
public:
HRESULT Initialize(PCWSTR path,
__in_opt PCWSTR verb,
const WinHttpConnection& connection)
{
HR(m_buffer.Initialize(8 * 1024));
// Call WinHttpOpenRequest and WinHttpSetStatusCallback.
}
HRESULT SendRequest(__in_opt PCWSTR headers,
DWORD headersLength,
__in_opt const void* optional,
DWORD optionalLength,
DWORD totalLength)
{
T* pT = static_cast<T*>(this);
// Call WinHttpSendRequest with pT as the context value.
}
protected:
static void CALLBACK Callback(HINTERNET handle,
DWORD_PTR context,
DWORD code,
void* info,
DWORD length)
{
if (0 != context)
{
T* pT = reinterpret_cast<T*>(context);
HRESULT result = pT->OnCallback(code,
info,
length);
if (FAILED(result))
{
pT->OnResponseComplete(result);
}
}
}
HRESULT OnCallback(DWORD code,
const void* info,
DWORD length)
{
// Handle notifications here.
}
SimpleBuffer m_buffer;
};
그림 6에는 DownloadFileRequest 클래스가 나와 있습니다. 이 클래스는 WinHttpRequest에서 파생되며 자신을 템플릿 매개 변수로 사용합니다. 이는 효율적인 컴파일 시간 가상 함수 호출을 구현하기 위해 Visual C++® 라이브러리에 많이 사용되는 기법입니다. WinHttpSession 및 WinHttpConnection 클래스와 마찬가지로 WinHttpRequest는 WinHTTP 요청 개체를 초기화하는 Initialize 멤버 함수를 제공합니다. WinHttpRequest 클래스는 먼저 요청 및 응답 데이터를 저장하는 데 사용할 버퍼를 만듭니다. 이 버퍼의 구현은 중요하지 않으며, BYTE 배열의 수명 주기를 관리하기만 하면 됩니다. Initialize 함수는 WinHttpOpenRequest를 호출하여 WinHTTP 요청 개체를 만들고 WinHttpSetStatusCallback을 호출하여 해당 개체를 WinHttpRequest 클래스 내에 있는 정적 Callback 멤버 함수에 연결합니다.
SendRequest 멤버 함수는 WinHttpSendRequest 함수를 래핑하고 이 함수의 "this" 포인터를 요청의 컨텍스트 값으로 전달하기만 합니다. 이 값이 콜백 함수에 전달되어 콜백 함수가 알림을 표시할 요청 개체를 결정할 수 있도록 한다고 앞서 설명했습니다. SendRequest는 static_cast를 사용하여 "this" 포인터를 템플릿 매개 변수에 지정된 파생 클래스로 조정합니다. 예제에서는 이 방식으로 컴파일 시간 다형성이 구현되었습니다.
마지막으로, Callback 멤버 함수가 컨텍스트 값을 다시 요청 개체에 대한 포인터로 캐스팅하고 OnCallback 멤버 함수를 호출하여 알림을 처리합니다. 네트워크 오류는 피할 수 없으므로 발생한 오류를 자연스럽게 처리할 수 있는 방법이 필요합니다. 파생 클래스는 HRESULT를 받는 OnResponseComplete 멤버 함수를 구현합니다. 이 함수에서 S_OK가 반환되면 요청이 성공적으로 완료된 것입니다. 하지만 콜백에 오류가 있으면 해당 HRESULT가 요청이 실패했음을 나타냅니다.
OnCallback 멤버 함수의 구현을 살펴보기 전에 그림 6의 구체적 클래스 DownloadFileRequest를 다시 살펴보면서 WinHttpRequest를 조망해보도록 하겠습니다. 여기에서 요점은 DownloadFileRequest가 파일 다운로드와 관련한 구체적인 사항에 초점을 맞출 수 있다는 점입니다. 이러한 이점은 HTTP 요청 관리의 복잡성에도 영향을 받지 않습니다. Initialize 멤버 함수는 다운로드할 파일 원본의 경로와 해당 파일을 쓸 대상 스트림을 받습니다. OnReadComplete 멤버 함수는 응답의 각 청크가 수신될 때마다 호출되고 OnResponseComplete는 요청이 완료될 때 호출됩니다. 그림 6 DownloadFileRequest 클래스
그림 6 DownloadFileRequest 클래스class DownloadFileRequest : public WinHttpRequest<DownloadFileRequest>
{
public:
HRESULT Initialize(PCWSTR source,
IStream* destination,
const WinHttpConnection& connection)
{
m_destination = destination;
return __super::Initialize(source,
0, // GET
connection);
}
HRESULT OnReadComplete(const void* buffer,
DWORD bytesRead)
{
return m_destination->Write(buffer,
bytesRead,
0); // ignored
}
void OnResponseComplete(HRESULT result)
{
if (S_OK == result)
{
// Download succeeded
}
}
private:
CComPtr<IStream> m_destination;
};
요청 알림
다음으로 OnCallback 멤버 함수 구현 방법을 살펴보겠습니다. 그림 7에서 보듯이 여기서도 파생 클래스를 가리키도록 "this" 포인터를 조정하기 위해 OnCallback에 static_cast가 사용됩니다. 그리고 다양한 알림을 처리하기 위해 switch 문이 사용됩니다. switch 문은 처리되지 않은 특정 알림이 있으면 S_FALSE를 반환합니다. 이는 파생 클래스에서 OnCallback 멤버 함수를 다시 정의하려는 경우에 유용할 수 있습니다. 그림 7 OnCallback 구현
그림 7 OnCallback 구현HRESULT OnCallback(DWORD code,
const void* info,
DWORD length)
{
T* pT = static_cast<T*>(this);
switch (code)
{
case <some notification code>:
{
// Handle specific notification here.
break;
}
default:
{
return S_FALSE;
}
}
return S_OK;
}
서버에 연결할 수 있다는 가정 하에 요청을 보낼 때 주의해야 할 첫 번째 알림은 WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE입니다. 이 알림은 WinHttpSendRequest 함수 호출이 성공적으로 완료되었음을 나타냅니다. 간단한 GET 요청을 보낸다면 이제 WinHttpReceiveResponse 함수를 호출하여 WinHTTP에 응답 읽기를 시작하도록 지시할 수 있습니다.:
case WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE:
{
if (!::WinHttpReceiveResponse(m_handle,
0)) // reserved
{
return HRESULT_FROM_WIN32(::GetLastError());
}
break;
}
응답이 수신되면 응답 헤더를 읽을 수 있음을 나타내는 WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE 알림을 받게 됩니다. 응용 프로그램과 관련이 있는 다양한 헤더를 쿼리할 수 있습니다. 적어도 서버에서 반환되는 HTTP 상태 코드는 반드시 쿼리해야 합니다. 헤더 정보는 WinHttpQueryHeaders 함수를 사용하여 검색할 수 있습니다. 간단한 구현에서는 요청이 성공적이었음을 나타내는 HTTP_STATUS_OK 상태 코드만 확인할 수도 있습니다(그림 8 참조). 그림 8 성공적인 요청 확인
그림 8 성공적인 요청 확인case WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE:
{
DWORD statusCode = 0;
DWORD statusCodeSize = sizeof(DWORD);
if (!::WinHttpQueryHeaders(m_handle,
WINHTTP_QUERY_STATUS_CODE | WINHTTP_QUERY_FLAG_NUMBER,
WINHTTP_HEADER_NAME_BY_INDEX,
&statusCode,
&statusCodeSize,
WINHTTP_NO_HEADER_INDEX))
{
return HRESULT_FROM_WIN32(::GetLastError());
}
if (HTTP_STATUS_OK != statusCode)
{
return E_FAIL;
}
if (!::WinHttpReadData(m_handle,
m_buffer.GetData(),
m_buffer.GetCount(),
0)) // async result
{
return HRESULT_FROM_WIN32(::GetLastError());
}
break;
}
WinHttpQueryHeaders는 단순히 명명된 특정 헤더의 텍스트 값을 반환하는 것이 아니라 대부분 헤더에 매핑되는 정보 플래그 집합을 제공하는 강력한 함수입니다. 이러한 플래그는 HTTP 요청/응답 상태의 다른 측면에 대한 액세스도 제공합니다.
그림 8에서는 서버에서 반환된 상태 코드를 검색하기 위해 WINHTTP_QUERY_STATUS_CODE 플래그를 사용하고 있습니다. 또한 WinHttpQueryHeaders에 값을 문자열이 아니라 32비트 숫자로 반환하도록 지시하는 WINHTTP_QUERY_FLAG_NUMBER 한정자도 사용했습니다.
세 번째 매개 변수는 쿼리할 헤더의 이름을 지정합니다. 이 매개 변수가 WINHTTP_HEADER_NAME_BY_INDEX이면 이전 매개 변수에 전달된 플래그가 반환할 정보를 나타냅니다. 다음 두 매개 변수는 정보를 수신할 버퍼를 지정합니다. 마지막 매개 변수는 이름이 같은 여러 헤더를 읽는 데 유용합니다. 이 매개 변수가 WINHTTP_NO_HEADER_INDEX이면 첫 번째 헤더의 값만 반환됩니다.
요청이 성공적이라고 판단되면 WinHttpReadData 함수를호출하여 응답 읽기를 시작할 수 있습니다. 두 번째와 세 번째 매개 변수는 데이터를 수신할 버퍼를 지정합니다. 이 예제에서는 WinHttpRequest 클래스 템플릿이 소유한 버퍼를 사용합니다. 마지막 매개 변수는 비동기 프로그래밍 모델을 사용하는 경우 0이어야 합니다.
응답 데이터가 충분히 수신되면 버퍼에 사용 가능한 데이터가 있음을 나타내는 WINHTTP_CALLBACK_STATUS_READ_COMPLETE 알림을 받습니다. 읽은 데이터 양은 OnCallback의 길이 매개 변수로 나타냅니다. 이 매개 변수 값은 0(사용 가능한 데이터가 더 이상 없음) 또는 최대 WinHttpReadData 함수 호출에 지정된 버퍼 크기까지 어떠한 값이든 될 수 있습니다(그림 9 참조). 그림 9 확인 알림
그림 9 확인 알림case WINHTTP_CALLBACK_STATUS_READ_COMPLETE:
{
if (0 < length)
{
HR(pT->OnReadComplete(m_buffer.GetData(),
length));
if (!::WinHttpReadData(m_handle,
m_buffer.GetData(),
m_buffer.GetCount(),
0)) // async result
{
return HRESULT_FROM_WIN32(::GetLastError());
}
}
else
{
pT->OnResponseComplete(S_OK);
}
break;
}
이제 그림 6의 DownloadFileRequest 클래스에 있는 "이벤트"가 정확히 어디에서 온 것인지 알 수 있습니다. WINHTTP_CALLBACK_STATUS_READ_COMPLETE 처리기는 데이터가 수신될 때마다 파생 클래스의 OnReadComplete 메서드를 호출합니다. 이어서 데이터의 다음 블록을 읽기 위해 WinHttpReadData가 호출됩니다. 마지막으로 더 이상 사용 가능한 데이터가 없으면 S_OK를 사용하여 파생 클래스의 OnResponseComplete 메서드를 호출함으로써 응답을 성공적으로 읽었음을 나타냅니다.
요청 취소
WinHTTP는 작업이 완료될 때마다 콜백 함수를 통해 응용 프로그램에 알림으로써 비교적 오류가 적은 비동기 완료 모델을 제공합니다. 하지만 콜백 함수를 실행하는 데에는 작업자 스레드가 사용되기 때문에 요청을 취소할 때는 세부 사항에 주의를 기울여야 합니다.
요청은 WinHttpCloseHandle 함수를 사용하여 요청 함수를 닫으면 간단하게 취소되지만 요청 핸들을 닫은 후에 도착하는 후속 콜백에 대비해야 합니다. WinHttpSetStatusCallback 함수를 호출하여 요청 핸들을 닫기 전에 더 이상 콜백해서는 안 된다는 사실을 나타낼 수도 있지만 WinHTTP는 이를 작업자 스레드와 동기화하지 않습니다.
따라서 모든 공유 상태가 적절하게 보호되도록 해야 합니다. 구체적으로 말하면 콜백과 공유되면서 보호되지 않은 모든 데이터는 WINHTTP_STATUS_CALLBACK_HANDLE_CLOSING 알림을 받을 때까지 해제되지 않아야 합니다.
또한 WinHttpCloseHandle에 대한 호출을 WinHttpReadData, WinHttpWriteData 및 WinHttpSendRequest 같은 요청 개체에 대해 작업을 수행하는 다른 함수와 동기화해야 합니다. 요청 취소는 비동기 WinHTTP에서 문제가 발생하기 쉬운 영역 중 하나이므로 취소와 관련한 코드를 신중히 검토해보아야 합니다.
요청 데이터 보내기
POST 요청의 경우에는 어떨까요? 다른 HTTP 동사를 사용하는 요청과는 달리 이러한 요청에는 추가 데이터가 요청의 본문 내용으로 포함되어 있습니다. 그림 10에는 GET 요청과 POST 요청을 모두 손쉽게 처리할 수 있도록 업데이트된 WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE 처리기가 나와 있습니다. 그림 10 GET 및 POST 요청 처리
그림 10 GET 및 POST 요청 처리case WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE:
case WINHTTP_CALLBACK_STATUS_WRITE_COMPLETE:
{
HRESULT result = pT->OnWriteData();
if (FAILED(result))
{
return result;
}
if (S_FALSE == result)
{
if (!::WinHttpReceiveResponse(m_handle,
0)) // reserved
{
return HRESULT_FROM_WIN32(::GetLastError());
}
}
break;
}
WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE 알림은 도착할 때 OnWriteData 멤버 함수를 호출하여 파생 클래스가 요청의 일부로서 데이터를 쓸 수 있도록 합니다. WinHttpRequest 클래스 템플릿은 단순히 S_FALSE를 반환하는 GET 요청의 기본 구현을 제공합니다. 데이터는 WinHttpWriteData 함수를 사용하여 쓸 수 있습니다.
if (!::WinHttpWriteData(request,
buffer,
count,
0)) // async result
{
// Call GetLastError for error information
}
두 번째와 세 번째 매개 변수는 쓸 데이터가 들어 있는 버퍼를 지정합니다. 데이터가 써지면 WINHTTP_CALLBACK_STATUS_WRITE_COMPLETE 알림이 도착합니다. 그리고 데이터의 다음 블록을 쓰기 위해 파생 클래스의 OnWriteData 멤버 함수가 다시 호출됩니다. 이 함수가 완료되면 S_FALSE가 반환되고 기본 클래스 처리기가 응답을 받기 위해 기존과 마찬가지로 WinHttpReceiveResponse를 계속 호출합니다.
다음 단계
물론 C++를 사용하여 HTTP 클라이언트 응용 프로그램을 작성하는 방법에 대해 설명할 내용이 아직 많이 남았지만 아쉽게도 지면이 모자랍니다. 하지만 작업을 시작하는 데 필요한 정보는 이 자세한 소개 기사를 통해 충분히 얻었으리라 믿습니다.
지금까지 살펴보았듯이 WinHTTP는 HTTP 클라이언트 응용 프로그램 작성에 사용할 수 있는 강력한 최신 API를 제공합니다. 이 기사에서 설명한 기능 외에도 다양한 인증 스키마 지원과 SSL용 인증서 제공 및 유효성 검사 기능을 비롯하여 몇 가지 중요한 기능도 제공합니다. 뿐만 아니라 URL 작성과 구문 분석에 필요한 함수까지 제공합니다. 효과적이고 확장성이 뛰어난 HTTP 클라이언트 응용 프로그램을 작성할 수 있는 우수한 플랫폼을 찾고 있다면 WinHTTP가 제격입니다.
안정적인 HTTP 클라이언트 응용 프로그램을 작성하는 데 있어서 걸림돌이 되는 문제 중 하나로, 일관된 프록시 설정 검색 방법의 부재를 들 수 있습니다. 서버에 연결할 수 없는 경우에는 어떻게 해야 할까요? 사용할 프록시 서버는 어떻게 결정할까요? 보편적인 표준은 없지만 대개 약간의 노력만 기울이면 사용할 프록시 서버를 쉽게 알아낼 수 있습니다. 아쉽게도 이러한 노력을 기울이기보다 단순히 사용자에게 프록시 서버의 이름을 묻는 응용 프로그램이 다수입니다. 하지만 개인적으로 소프트웨어는 대개 스스로 알아낼 수 있는 정보를 사용자에게 제공하도록 요구하지 않을 만큼은 지능적이어야 한다고 생각합니다.
프록시 설정은 몇 곳에서 조회할 수 있습니다. 먼저 가장 단순한 방법부터 알아보게습니다. 개체에 대해 설명하면서 새 세션 개체를 만드는 데 사용되는 WinHttpOpen 함수를 소개했습니다:앞에서 자세히 설명하지 않았지만 이 함수에는 프록시 설정에 사용되는 매개 변수가 몇 개 있습니다. 여기서는 이러한 매개 변수의 기능에 대해 자세히 설명하겠습니다. 두 번째 매개 변수는 액세스 유형을 지정합니다. 그림 A에는 사용 가능한 값이 나열되어 있습니다.
HINTERNET session = ::WinHttpOpen(0, // no agent string
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY,
WINHTTP_NO_PROXY_NAME,
WINHTTP_NO_PROXY_BYPASS,
WINHTTP_FLAG_ASYNC);
그림 A 세션 액세스 유형| 세션 개체 매개 변수 | 설명 |
|---|---|
| WINHTTP_ACCESS_TYPE_NO_PROXY | 기본적으로 프록시 서버를 사용하지 않습니다. |
| WINHTTP_ACCESS_TYPE_DEFAULT_PROXY | 레지스트리에 저장된 WinHTTP 프록시 설정을 사용합니다. |
| WINHTTP_ACCESS_TYPE_NAMED_PROXY | 지정한 프록시 설정을 사용합니다. |
WINHTTP_ACCESS_TYPE_NO_PROXY는 프록시 설정하거나 사용하지 않아야 함을 나타냅니다. 이 값은 세션을 만든 후에 다시 정의할 수 있으며 그 방법은 잠시 후에 설명하겠습니다.
WINHTTP_ACCESS_TYPE_DEFAULT_PROXY는 WinHTTP가 레지스트리에 저장한 프록시 설정을 사용해야 함을 나타냅니다. 이 매개 변수는 관리자가 프록시 설정을 제어하도록 할 때 유용합니다. 또한 Internet Explorer의 프록시 설정과는 별개이며, 따라서 서버 시나리오에 적합합니다. Windows XP 및 Windows Server 2003에서는 proxycfg.exe 유틸리티를 사용하여 WinHTTP 프록시 설정을 구성하고 쿼리할 수 있습니다. Windows Vista 및 Windows Server 2008에서는 proxycfg.exe 유틸리티 대신 netsh.exe 유틸리티가 해당 기능을 제공합니다. WinHttpSetDefaultProxyConfiguration 함수를 사용하여 WinHTTP 프록시 설정을 직접 설정하고 WinHttpGetDefaultProxyConfiguration 함수를 사용하여 쿼리할 수도 있습니다. 이러한 설정은 다시 부팅해도 그대로 유지되며 모든 로그온 세션에서 공유됩니다. 두 함수는 모두 WinHttpOpen 함수의 세 가지 프록시 관련 매개 변수에 직접 매핑되는 WINHTTP_PROXY_INFO 구조를 사용합니다.
WINHTTP_ACCESS_TYPE_NAMED_PROXY는 WinHTTP에 다음 두 매개 변수에 지정된 프록시 설정을 사용해야 함을 나타냅니다. WinHttpOpen의 세 번째 매개 변수는 프록시 서버의 이름을 지정하고 네 번째 매개 변수는 이전 매개 변수에 지정된 프록시 서버를 통해 라우팅되면 안 되는 HTTP 서버의 선택적 목록을 지정합니다.
Windows 서비스 또는 서버 응용 프로그램을 작성하는 경우 이것만으로 충분할 것입니다. 하지만 최종 사용자는 보통 프록시 설정에 대해 잘 모르거나 프록시 설정을 구성하기를 꺼리므로 가능한 한 쉽게 만들기 위해 약간의 노력을 더 기울어야 합니다. 대부분의 사용자는 이미 웹 프록시를 통해 웹에 액세스할 수 있도록 브라우저를 구성해놓았을 것이므로 Internet Explorer의 프록시 설정을 검색하는 것도 하나의 방법이 될 수 있습니다. Internet Explorer의 프록시 설정에 사용되는 대화 상자는 Internet Explorer 옵션 창의 연결 탭에서 "LAN 설정" 단추를 클릭하면 열 수 있습니다. 이는 일반적인 요구 사항이므로 WinHTTP는 현재 사용자의 Internet Explorer 프록시 설정을 직접 검색할 수 있는 WinHttpGetIEProxyConfigForCurrentUser 함수를 제공합니다.
WINHTTP_CURRENT_USER_IE_PROXY_CONFIG ieProxyConfig = { 0 };
if (!::WinHttpGetIEProxyConfigForCurrentUser(&ieProxyConfig))
{
// Call GetLastError for error information.
}
Here's what WINHTTP_CURRENT_USER_IE_PROXY_CONFIG looks like:
struct WINHTTP_CURRENT_USER_IE_PROXY_CONFIG
{
BOOL fAutoDetect;
LPWSTR lpszAutoConfigUrl;
LPWSTR lpszProxy;
LPWSTR lpszProxyBypass;
};
null이 아닌 문자열 멤버 변수는 GlobalFree 함수를 사용하여 해제해야 합니다. fAutoDetect 멤버는 LAN 설정 대화 상자의 "자동으로 설정 검색" 옵션에 매핑됩니다. lpszAutoConfigUrl 멤버는 "자동 구성 스크립트 사용" 주소에 매핑되고 이 옵션을 선택한 경우에 채워집니다. lpszProxy 멤버는 "프록시 서버 사용..." 주소 및 포트에 매핑되고 이 옵션을 선택한 경우에만 채워집니다. 마지막으로 lpszProxyBypass는 고급 단추를 클릭하면 나타나는 창의 예외 영역에 지정된 서버 목록에 매핑되고 "로컬 주소에 프록시 서버 사용 안 함" 옵션을 선택한 경우에만 채워집니다.
lpszProxy가 채워지면 해당 값을 프록시 서버로 사용할 수 있으므로 간단합니다. 다른 옵션의 경우 프록시 서버 설정을 확인하려면 약간의 추가 작업이 필요합니다.
lpszAutoConfigUrl가 채워지면 Internet Explorer가 특정 연결에 사용할 프록시 서버를 결정하기 위해 PAC(프록시 자동 구성) 파일을 다운로드했음을 의미합니다. PAC 파일에는 대상 서버에 따라 클라이언트에 특정 프록시 서버를 사용하도록 지시하는 JavaScript가 포함되어 있는 경우가 많으므로 이 동작을 재현하기가 어려울 수 있습니다. 다행히 WinHTTP는 이를 자동으로 추출하는 WinHttpGetProxyForUrl 함수를 제공합니다.
WINHTTP_AUTOPROXY_OPTIONS autoProxyOptions = { 0 };
autoProxyOptions.dwFlags = WINHTTP_AUTOPROXY_CONFIG_URL;
autoProxyOptions.lpszAutoConfigUrl = ieProxyConfig.lpszAutoConfigUrl;
WINHTTP_PROXY_INFO proxyInfo = { 0 };
if (!::WinHttpGetProxyForUrl(session,
L"http://example.com/path",
&autoProxyOptions,
&proxyInfo))
{
// Call GetLastError for error information.
}
WINHTTP_PROXY_INFO 구조의 null이 아닌 문자열 멤버 변수도 GlobalFree 함수를 사용하여 해제해야 합니다. 첫 번째 WinHttpGetProxyForUrl 매개 변수는 WinHTTP 세션 핸들을 지정합니다. 두 번째 매개 변수는 보낼 요청의 URL을 지정합니다. 세 번째 매개 변수는 input 매개 변수로, WinHttpGetProxyForUrl 함수의 동작을 제어하는 WINHTTP_AUTOPROXY_OPTIONS 구조를 지정합니다. Internet Explorer 프록시 설정에서 검색된 PAC 파일의 URL은 이 매개 변수를 통해 지정합니다. 마지막 매개 변수는 out 매개 변수로 결과를 검색하는 WINHTTP_PROXY_INFO 구조를 지정합니다. 검색된 결과는 WINHTTP_OPTION_PROXY 옵션과 함께 WinHttpSetOption 함수에 사용하여 특정 요청 개체의 프록시 설정을 지정할 수 있습니다.
마지막으로 WINHTTP_CURRENT_USER_IE_PROXY_CONFIG의 fAutoDetect 멤버 변수가 true이면 Internet Explorer가 WPAD(웹 프록시 자동 검색) 프로토콜을 사용하여 프록시 설정을 검색함을 의미합니다. WPAD는 네트워크의 DNS 또는 DHCP 서버에 대한 업데이트를 통해 PAC 스크립트의 URL을 제공하므로 특정 PAC 스크립트로 클라이언트를 미리 구성할 필요가 없습니다. 이는 정적 IP 주소 및 동적 IP 주소 사이의 관계와 유사합니다. 다음과 같이 WPAD를 사용하여 WINHTTP_AUTOPROXY_OPTIONS 초기화를 변경함으로써 PAC 파일의 URL을 검색하도록 WinHttpGetProxyForUrl에 지시할 수 있습니다.
WINHTTP_AUTOPROXY_OPTIONS autoProxyOptions = { 0 };
autoProxyOptions.dwFlags = WINHTTP_AUTOPROXY_AUTO_DETECT;
autoProxyOptions.dwAutoDetectFlags = WINHTTP_AUTO_DETECT_TYPE_DHCP
| WINHTTP_AUTO_DETECT_TYPE_DNS_A;
물론 Internet Explorer에 의존하지 않고 WinHTTP "AutoProxy" 기능을 사용할 수도 있습니다. Internet Explorer 설정을 사용하는 방법은 주로 회사 네트워크 환경에서 WPAD가 확산될 때까지 미봉책으로 활용됩니다. 네트워크에서 WPAD를 사용할 수 없으면 WinHttpGetProxyForUrl가 반환되는 데 몇 초 걸릴 수 있으며 GetLastError가 ERROR_WINHTTP_AUTODETECTION_FAILED를 반환하게 됩니다.
'저장소 > VC++' 카테고리의 다른 글
| How to use VC_EXTRALEAN and WIN32_LEAN_AND_MEAN to enhance the build process in Visual C++ (0) | 2013.11.19 |
|---|---|
| PSAPI 사용 주의 (0) | 2013.11.19 |
| 윈도우의 오류 메커니즘(마이크로소프트웨어 신영진님 기고글) (0) | 2013.10.23 |
| Stream Manipulators (0) | 2013.08.16 |
| System Performance Monitoring (0) | 2013.08.06 |