Ureader.com  
Microsoft software help and Community
   home   |   control panel login   |   archive   |  
 
inet
active_desktop
active_scrptng
asp.components
asp.db
asp.general
comctl32
comp.packaging
components.dev
dbweb
dhtml_editing
docobjects
html_authoring
html_objmodel
iis
iis.ftp
iis.security
iis.smtp_nntp
indexserver
misc
mshtml_hosting
scripting.jscript
scripting.vbscript
sdk_setup
shell_objmodel
urlmonikers
webbrowser_ctl
wininet
  
 
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

Google
 
Web ureader.com


    COPYRIGHT 2007, YARDI TECHNOLOGY LIMITED, ALL RIGHT RESERVE  |   contact us