|
|
|
date: Fri, 26 Oct 2007 07:34:51 -0700,
group: microsoft.public.inetsdk.programming.webbrowser_ctl
back
Alter querystring through APP
While using Igor's Passthru APP I need to add a querystring to a
requested url.
In my Start() method I am appending the querystring to szUrl
parameter and calling target app's Start() method with the new URL
with querystring. The request gets sent with the new url.
STDMETHODIMP CTestAPP::Start(
LPCWSTR szUrl, IInternetProtocolSink *pOIProtSink,
IInternetBindInfo *pOIBindInfo, DWORD grfPI, HANDLE_PTR dwReserved)
{
LPCWSTR szUrlQuery = szUrl + querystring //add querystring to url
targetApp -> Start(szUrlQuery, ...) //call target app's start with new
url
}
In my ReportData() method my App calls targetSink's ReportProgress
method with BINDSTATUS_REDIRECTING flag with the new URL (szUrlQuery)
to notify the request URL had been changed.
STDMETHODIMP CTestSink::ReportData(
/* [in] */ DWORD grfBSCF,
/* [in] */ ULONG ulProgress,
/* [in] */ ULONG ulProgressMax)
{
m_spInternetProtocolSink->ReportProgress(BINDSTATUS_REDIRECTING,
szUrlQuery); //notify redirect with new URL with querystring
m_spInternetProtocolSink->ReportData((BSCF_FIRSTDATANOTIFICATION |
BSCF_LASTDATANOTIFICATION | BSCF_DATAFULLYAVAILABLE), dwLegth,
dwLegth); //notify target sink of data
hr = m_spInternetProtocolSink->ReportResult(S_OK, S_OK, NULL);
}
I tested by typing URL without querystring in the address bar and saw
how APP added the querystring and sent correct request. I receive
the correct form and the browser address bar displays the new URL with
the querystring.
However, when I submit the form, that is suppose to request the same
URL+ querystring, the browser sends to APP a request without the
querystring. Why does this happen?
If I ignore this problem and have my APP add the querystring to the
URL on the second request, then the page will appear in browser in
exactly the same way as before. However when I submit the form again
(3-request) , the browser doesn't send the request (and app doesn't
start) and gives "The webpage cannot be displayed" message. Also the
browser address bar shows some gibberish. Does anybody know what I am
doing wrong?
date: Fri, 26 Oct 2007 07:34:51 -0700
author: Max K.
Re: Alter querystring through APP
Max K. wrote:
> While using Igor's Passthru APP I need to add a querystring to a
> requested url.
> In my Start() method I am appending the querystring to szUrl
> parameter and calling target app's Start() method with the new URL
> with querystring. The request gets sent with the new url.
>
> STDMETHODIMP CTestAPP::Start(
> LPCWSTR szUrl, IInternetProtocolSink *pOIProtSink,
> IInternetBindInfo *pOIBindInfo, DWORD grfPI, HANDLE_PTR dwReserved)
>
> {
> LPCWSTR szUrlQuery = szUrl + querystring //add querystring to url
This is pseudocode, right? It doesn't make sense as actual code.
> targetApp -> Start(szUrlQuery, ...) //call target app's start with new
> url
> }
>
> In my ReportData() method my App calls targetSink's ReportProgress
> method with BINDSTATUS_REDIRECTING flag with the new URL (szUrlQuery)
> to notify the request URL had been changed.
>
> STDMETHODIMP CTestSink::ReportData(
> /* [in] */ DWORD grfBSCF,
> /* [in] */ ULONG ulProgress,
> /* [in] */ ULONG ulProgressMax)
> {
>
> m_spInternetProtocolSink->ReportProgress(BINDSTATUS_REDIRECTING,
> szUrlQuery); //notify redirect with new URL with querystring
Move that to Start, right before calling Start on target APP. ReportData
is called multiple times, you don't want to report
BINDSTATUS_REDIRECTING more than once.
> m_spInternetProtocolSink->ReportData((BSCF_FIRSTDATANOTIFICATION |
> BSCF_LASTDATANOTIFICATION | BSCF_DATAFULLYAVAILABLE), dwLegth,
> dwLegth); //notify target sink of data
You tell the client that data is fully avaialble. Is it? How do you know
it is? What makes you so sure the target APP will give you all the data
in one big chunk? Why don't you just pass along the same parameters you
got?
> hr = m_spInternetProtocolSink->ReportResult(S_OK, S_OK, NULL);
Same question - when the first ReportData arrives, what makes you so
sure the result is going to be OK? That the connection won't get dropped
before the next chunk of data makes it to you?
> However, when I submit the form, that is suppose to request the same
> URL+ querystring, the browser sends to APP a request without the
> querystring. Why does this happen?
POST requests don't encode form parameters into the URL, but send them
as POST data. What does the <form> tag look like for the form you are
submitting? In particular, what is the method= attribute set to?
> If I ignore this problem and have my APP add the querystring to the
> URL on the second request
What do you mean by "second request"? I assume there's also a "first"?
How do the two differ?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Fri, 26 Oct 2007 11:55:56 -0400
author: Igor Tandetnik
Re: Alter querystring through APP
On Oct 26, 11:55 am, "Igor Tandetnik" wrote:
> Max K. wrote:
> > While using Igor's Passthru APP I need to add a querystring to a
> > requested url.
> > In my Start() method I am appending the querystring to szUrl
> > parameter and calling target app's Start() method with the new URL
> > with querystring. The request gets sent with the new url.
>
> > STDMETHODIMP CTestAPP::Start(
> > LPCWSTR szUrl, IInternetProtocolSink *pOIProtSink,
> > IInternetBindInfo *pOIBindInfo, DWORD grfPI, HANDLE_PTR dwReserved)
>
> > {
> > LPCWSTR szUrlQuery = szUrl + querystring //add querystring to url
>
> This is pseudocode, right? It doesn't make sense as actual code.
Correct. This is pseudocode. Sorry I did not point it out.
> > targetApp -> Start(szUrlQuery, ...) //call target app's start with new
> > url
> > }
>
> > In my ReportData() method my App calls targetSink's ReportProgress
> > method with BINDSTATUS_REDIRECTING flag with the new URL (szUrlQuery)
> > to notify the request URL had been changed.
>
> > STDMETHODIMP CTestSink::ReportData(
> > /* [in] */ DWORD grfBSCF,
> > /* [in] */ ULONG ulProgress,
> > /* [in] */ ULONG ulProgressMax)
> > {
>
> > m_spInternetProtocolSink->ReportProgress(BINDSTATUS_REDIRECTING,
> > szUrlQuery); //notify redirect with new URL with querystring
>
> Move that to Start, right before calling Start on target APP. ReportData
> is called multiple times, you don't want to report
> BINDSTATUS_REDIRECTING more than once.
>
> > m_spInternetProtocolSink->ReportData((BSCF_FIRSTDATANOTIFICATION |
> > BSCF_LASTDATANOTIFICATION | BSCF_DATAFULLYAVAILABLE), dwLegth,
> > dwLegth); //notify target sink of data
>
> You tell the client that data is fully avaialble. Is it? How do you know
> it is? What makes you so sure the target APP will give you all the data
> in one big chunk? Why don't you just pass along the same parameters you
> got?
>
> > hr = m_spInternetProtocolSink->ReportResult(S_OK, S_OK, NULL);
>
> Same question - when the first ReportData arrives, what makes you so
> sure the result is going to be OK? That the connection won't get dropped
> before the next chunk of data makes it to you?
I checked all of that before. My App calls target
ReportProgress(BINDSTATUS_REDIRECTING), ReportData(), ReportResult()
only once. This is just pseudocode.
>
> > However, when I submit the form, that is suppose to request the same
> > URL+ querystring, the browser sends to APP a request without the
> > querystring. Why does this happen?
>
> POST requests don't encode form parameters into the URL, but send them
> as POST data. What does the <form> tag look like for the form you are
> submitting? In particular, what is the method= attribute set to?
In my case I have an empty form, with method = POST and action is
blank. It means that it has to send an empty POST request to the same
URL + querystring that was on the address bar. Correct?
>
> > If I ignore this problem and have my APP add the querystring to the
> > URL on the second request
>
> What do you mean by "second request"? I assume there's also a "first"?
> How do the two differ?
The first was initiated by typing URL in Browser address bar. The
second request was hitting submit on the form returned by the first
request.
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925- Hide quoted text -
>
> - Show quoted text -
My general question: is it possible for the APP to change URL after
request was initiated by browser? In my test described above I was
only able to change the URL for 2 consecutive requests and then on the
3-rd request the browser stopped working.
date: Fri, 26 Oct 2007 11:08:08 -0700
author: Max K.
Re: Alter querystring through APP
Max K. wrote:
> On Oct 26, 11:55 am, "Igor Tandetnik" wrote:
> In my case I have an empty form, with method = POST and action is
> blank. It means that it has to send an empty POST request to the same
> URL + querystring that was on the address bar. Correct?
What do you mean, an _empty_ POST request? Form fields go into the POST
body.
I'm not sure what hapens when action= is empty. I wouldn't be surprised
if the browser takes the page's URL, strips the part after the question
mark and uses the stripped URL to submit the form. It is highly unusual,
though not technically prohibited by the protocol, to send a POST
request (with parameters in the body) to a URL that also specifies
parameters.
>>> If I ignore this problem and have my APP add the querystring to the
>>> URL on the second request
>>
>> What do you mean by "second request"? I assume there's also a
>> "first"? How do the two differ?
>
> The first was initiated by typing URL in Browser address bar. The
> second request was hitting submit on the form returned by the first
> request.
So you have the same handler on the server responding both to GET and
POST requests? Where does it take parameters from, when they are
specified both in the URL and the POST body? Make sure it doesn't get
confused when it gets such a request - or better yet, avoid this
situation in the first place.
> My general question: is it possible for the APP to change URL after
> request was initiated by browser?
I believe what you are doing should work: pass a new URL down to the
target APP's Start() method, and report the new URL back to the browser
with BINDSTATUS_REDIRECTING. I suspect your games with putting query
parameters on a POST request is what's confusing the browser.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
date: Fri, 26 Oct 2007 16:29:27 -0400
author: Igor Tandetnik
|
|