Hi.
Recently I tried to start with this interface. It looks trivial enough but since it's first time i'm using winhttp, there could be some problems, especially cause IXMLHTTPRequest supports asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to far from reality?
P.S. any comments are welcome actually.
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough but since it's first time i'm using winhttp, there could be some problems, especially cause IXMLHTTPRequest supports asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp, which may already handle asynchronous requests.
-Hans
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough but since it's first time i'm using winhttp, there could be some problems, especially cause IXMLHTTPRequest supports asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp, which may already handle asynchronous requests.
-Hans
Such things: --- static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface, DWORD dwOption, void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD *pdwReserved) { HttpProtocol *This = INETINFO_THIS(iface); FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer, pcbBuffer, pdwFlags, pdwReserved); return E_NOTIMPL; } --- static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface, HRESULT hrReason, DWORD dwOptions) { HttpProtocol *This = PROTOCOL_THIS(iface); FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions); return E_NOTIMPL; } --- make me think it's not ready. Also IXMLHTTPRequest methods look to directly map tp Winhttp calls. For example how can I implement IXMLHTTPRequest::setRequestHeader() with urlmon?
Btw, what was a reason for using it?
On Sunday 07 February 2010 15:08:33 Nikolay Sivov wrote:
Such things:
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface, HRESULT hrReason, DWORD dwOptions) { HttpProtocol *This = PROTOCOL_THIS(iface); FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions); return E_NOTIMPL; }
make me think it's not ready. Also IXMLHTTPRequest methods look to directly map tp Winhttp calls.
Sure there are stubs, but implementing those should not be much different from what you've written now. The question is, does urlmon map better to IXMLHTTPRequest than winhttp?
For example how can I implement IXMLHTTPRequest::setRequestHeader() with urlmon?
Now this might be a good reason to go with winhttp instead of urlmon. In that case the (unimplemented) WinHttpRequest object is probably a better fit than the C interface.
Btw, what was a reason for using it?
I think it's just a matter of trying to avoid code duplication.
-Hans
On 2/7/10 3:08 PM, Nikolay Sivov wrote:
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough but since it's first time i'm using winhttp, there could be some problems, especially cause IXMLHTTPRequest supports asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp, which may already handle asynchronous requests.
-Hans
Such things:
static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface, DWORD dwOption, void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD *pdwReserved) { HttpProtocol *This = INETINFO_THIS(iface); FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer, pcbBuffer, pdwFlags, pdwReserved); return E_NOTIMPL; }
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface, HRESULT hrReason, DWORD dwOptions) { HttpProtocol *This = PROTOCOL_THIS(iface); FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions); return E_NOTIMPL; }
make me think it's not ready.
Even if that's true, it's not a reason to choose wrong architecture.
Also IXMLHTTPRequest methods look to directly map tp Winhttp calls. For example how can I implement IXMLHTTPRequest::setRequestHeader() with urlmon?
By implementing IHttpNegotiate on bind status callback.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet.
Jacek
On 2/8/2010 05:24, Jacek Caban wrote:
On 2/7/10 3:08 PM, Nikolay Sivov wrote:
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough but since it's first time i'm using winhttp, there could be some problems, especially cause IXMLHTTPRequest supports asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp, which may already handle asynchronous requests.
-Hans
Such things:
static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface, DWORD dwOption, void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD *pdwReserved) { HttpProtocol *This = INETINFO_THIS(iface); FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer, pcbBuffer, pdwFlags, pdwReserved); return E_NOTIMPL; }
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface, HRESULT hrReason, DWORD dwOptions) { HttpProtocol *This = PROTOCOL_THIS(iface); FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions); return E_NOTIMPL; }
make me think it's not ready.
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon.
Also IXMLHTTPRequest methods look to directly map tp Winhttp calls. For example how can I implement IXMLHTTPRequest::setRequestHeader() with urlmon?
By implementing IHttpNegotiate on bind status callback.
Thanks, will take a look.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet.
Why IXMLHTTPRequest is IE related? Or you mean that anything that uses internet should go through urlmon?
Jacek
On 2/8/10 3:36 AM, Nikolay Sivov wrote:
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon.
We don't have, it's impossible. Pluggable protocol is one of the reasons and you can't handle them unless you use urlmon.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet.
Why IXMLHTTPRequest is IE related? Or you mean that anything that uses internet should go through urlmon?
It is designed to be used by JScript scripts on web pages (although it's not the only use of it).
Jacek
On 2/8/2010 05:55, Jacek Caban wrote:
On 2/8/10 3:36 AM, Nikolay Sivov wrote:
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon.
We don't have, it's impossible. Pluggable protocol is one of the reasons and you can't handle them unless you use urlmon.
What's impossible? Yes, I can't handle pluggable protocol without urlmon, but why do I need it? Maybe I'm missing something but I don't see why IXMLHTTP needs more than just http.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet.
Why IXMLHTTPRequest is IE related? Or you mean that anything that uses internet should go through urlmon?
It is designed to be used by JScript scripts on web pages (although it's not the only use of it).
Ah, so you mean using urlmon enables session sharing within browser context? (I didn't know that) If so, i should use it of course, instead of direct connection.
Jacek
On 2/8/10 1:19 PM, Nikolay Sivov wrote:
On 2/8/2010 05:55, Jacek Caban wrote:
On 2/8/10 3:36 AM, Nikolay Sivov wrote:
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon.
We don't have, it's impossible. Pluggable protocol is one of the reasons and you can't handle them unless you use urlmon.
What's impossible? Yes, I can't handle pluggable protocol without urlmon, but why do I need it? Maybe I'm missing something but I don't see why IXMLHTTP needs more than just http.
Using pluggable protocols has visible effect for apps (eg. an app may override http handler or use mime filters), so if native msxml3 uses it, we should use it as well and there is no way around. Also I don't know if native limits requests to http protocol, but (forgetting about its name) there is no reason it can't work for other protocols and you get it for free with urlmon.
Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet.
Why IXMLHTTPRequest is IE related? Or you mean that anything that uses internet should go through urlmon?
It is designed to be used by JScript scripts on web pages (although it's not the only use of it).
Ah, so you mean using urlmon enables session sharing within browser context? (I didn't know that) If so, i should use it of course, instead of direct connection.
Yes.
Jacek
On 2/8/2010 16:38, Jacek Caban wrote:
On 2/8/10 1:19 PM, Nikolay Sivov wrote:
On 2/8/2010 05:55, Jacek Caban wrote:
On 2/8/10 3:36 AM, Nikolay Sivov wrote:
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon.
We don't have, it's impossible. Pluggable protocol is one of the reasons and you can't handle them unless you use urlmon.
What's impossible? Yes, I can't handle pluggable protocol without urlmon, but why do I need it? Maybe I'm missing something but I don't see why IXMLHTTP needs more than just http.
Using pluggable protocols has visible effect for apps (eg. an app may override http handler or use mime filters), so if native msxml3 uses it, we should use it as well and there is no way around. Also I don't know if native limits requests to http protocol, but (forgetting about its name) there is no reason it can't work for other protocols and you get it for free with urlmon.
Ok. Thanks.
-
Hans Leidekker -
Jacek Caban -
Nikolay Sivov