steva
asked on
Basic difference between a browser access and a form access
When you drop a URL into a browser, the browser delivers the page to your screen. Or the selected page could do a redirect and then you'd get a different page on your screen. In either case, your connected to the page. But if you submit a form, you send off some variables to some Action page, and you're never connected to that page. It all happens out of view, under the table. If the Action page did a response.write() , for example, you wouldn't see it. Yet both the browser access and the form access use a normal HTTP GET or POST to the target page. So what exactly is the fundamental difference between these accesses?
Thanks for any thoughts.
Thanks for any thoughts.
ASKER
Joseph,,
Thanks for the response, but I know the difference between POST and GET. The issue the difference between a browser access to a page and a form access to a page. Why is one able to do a response.write() back to the caller and the other can't?
Thanks for the response, but I know the difference between POST and GET. The issue the difference between a browser access to a page and a form access to a page. Why is one able to do a response.write() back to the caller and the other can't?
>If the Action page did a response.write() , for example, you wouldn't see it.
Your application need to listen for it, could you confirm it's currently the case ?
>So what exactly is the fundamental difference between these accesses?
With a web application/a browser you have objects (response, request, Server and so on) provided to you to send and get data
With a desktop application you need to do the job yourself (to send and listen for data) with socket, stream like object. You may found library/framework doing part of the job.
Assuming you create your application with c++ using sockets, here an example where we can see we're receiving the response (the famous response.write()) from the server :
http://www.zedwood.com/article/113/cpp-winsock-basic-http-connection
Your application need to listen for it, could you confirm it's currently the case ?
>So what exactly is the fundamental difference between these accesses?
With a web application/a browser you have objects (response, request, Server and so on) provided to you to send and get data
With a desktop application you need to do the job yourself (to send and listen for data) with socket, stream like object. You may found library/framework doing part of the job.
Assuming you create your application with c++ using sockets, here an example where we can see we're receiving the response (the famous response.write()) from the server :
http://www.zedwood.com/article/113/cpp-winsock-basic-http-connection
>Why is one able to do a response.write() back to the caller and the other can't?
If you listen for the response you will get it.
If you listen for the response you will get it.
ASKER
Hi leakim,
Ok, you may have answered it. But let me be a bit more specific. I wasn't thinking of a desktop application, here. The example that raised the question is a PayPal "Buy Now" button. As you probably know, the button itself is a form you paste into your HTML page with the Action item pointing to PayPay. When the button is clicked, PayPal responds, after processing the buyer's credit card, with a POST back to your "notify_url " passing you all the transaction data so you can update your database. You tell PayPal where the notify_url is when you initially set up the button on their site.
So you have a page on your server - the notify_url - that receives this POST and needs to update a database with the information. But troubleshooting the notify_url script is difficult because anything you might want to have it report to you, with a Response.Write() for example, isn't seen.
It occurred to me that every form that posts back to a different page is in the same situation. When a _browser_ does a POST or a GET, it gets a connection to the page, so if the accessed page is aspx the VB can do a Response.Write() and you see the output. But if a _form_ on the downloaded page submits to some other processing url, you don't see what processing script writes with Response.Write(). One has a connection back to the client and one doesn't. I'm just trying to grasp exactly what's going on here.
Are you saying that if I set up a listener for the processing url, or the notify_url for the PayPal case, that I could see the Respone.Write() outputs, and that that the browser does this automatically?
Ok, you may have answered it. But let me be a bit more specific. I wasn't thinking of a desktop application, here. The example that raised the question is a PayPal "Buy Now" button. As you probably know, the button itself is a form you paste into your HTML page with the Action item pointing to PayPay. When the button is clicked, PayPal responds, after processing the buyer's credit card, with a POST back to your "notify_url " passing you all the transaction data so you can update your database. You tell PayPal where the notify_url is when you initially set up the button on their site.
So you have a page on your server - the notify_url - that receives this POST and needs to update a database with the information. But troubleshooting the notify_url script is difficult because anything you might want to have it report to you, with a Response.Write() for example, isn't seen.
It occurred to me that every form that posts back to a different page is in the same situation. When a _browser_ does a POST or a GET, it gets a connection to the page, so if the accessed page is aspx the VB can do a Response.Write() and you see the output. But if a _form_ on the downloaded page submits to some other processing url, you don't see what processing script writes with Response.Write(). One has a connection back to the client and one doesn't. I'm just trying to grasp exactly what's going on here.
Are you saying that if I set up a listener for the processing url, or the notify_url for the PayPal case, that I could see the Respone.Write() outputs, and that that the browser does this automatically?
>But troubleshooting the notify_url script is difficult because anything you might want to have it report to you, with a Response.Write() for example, isn't seen.
You may temporary replace your current notify page by a page doing a dump of the paypal POST in a file.
For example with PHP, check this : http://www.fijiwebdesign.com/blog/acess-the-http-request-headers-and-body-via-php.html
>Are you saying that if I set up a listener for the processing url, or the notify_url for the PayPal case, that I could see the Respone.Write() outputs, and that that the browser does this automatically?
If you've a web server, it already listen for connexion so no need.
Do you have you web application hosted or you have your own server at "home" ?
If you have full access to the web server you may use specific tools to capture traffic
You may temporary replace your current notify page by a page doing a dump of the paypal POST in a file.
For example with PHP, check this : http://www.fijiwebdesign.com/blog/acess-the-http-request-headers-and-body-via-php.html
>Are you saying that if I set up a listener for the processing url, or the notify_url for the PayPal case, that I could see the Respone.Write() outputs, and that that the browser does this automatically?
If you've a web server, it already listen for connexion so no need.
Do you have you web application hosted or you have your own server at "home" ?
If you have full access to the web server you may use specific tools to capture traffic
If it's not already the case check page 343 here : https://www.paypalobjects.com/WEBSCR-640-20100907-1/en_US/pdf/PP_WebsitePaymentsStandard_IntegrationGuide.pdf
as you can see, the client (Customer browser) post data only one time.
as you can see, the client (Customer browser) post data only one time.
ASKER
My web application is hosted so I don't have full access to the server.
I guess the only question I still have is how do developers troubleshoot scripts that process forms? I can see that you could have the script write to a file, but there must be some way to get direct control from your browser, so you can see the Response.Writes it generates.
I guess the only question I still have is how do developers troubleshoot scripts that process forms? I can see that you could have the script write to a file, but there must be some way to get direct control from your browser, so you can see the Response.Writes it generates.
Please confirm your server language ? Classic ASP, ASP.NET, PHP or Java based ?
To troubleshoot, build a dedicated page receiving the IPN post and save it in a flat file.
Use the url to this "page as notify_url
To troubleshoot, build a dedicated page receiving the IPN post and save it in a flat file.
Use the url to this "page as notify_url
ASKER
The server is running ASP.NET and I use VB for scripting.
"To troubleshoot, build a dedicated page receiving the IPN post and save it in a flat file.
Use the url to this "page as notify_url"
I'm not following this, Leakim. . I already have a dedicated page on my server to receive and process the IPN post at IPNListener.aspx. What do you mean by "save it in a flat file and use the url to this file as the notify_url"? How is that different than what I'm doing?
"To troubleshoot, build a dedicated page receiving the IPN post and save it in a flat file.
Use the url to this "page as notify_url"
I'm not following this, Leakim. . I already have a dedicated page on my server to receive and process the IPN post at IPNListener.aspx. What do you mean by "save it in a flat file and use the url to this file as the notify_url"? How is that different than what I'm doing?
>I already have a dedicated page on my server to receive and process the IPN post at IPNListener.aspx.
Yes, I know. But to troubleshoot you may create an another/additional page doing a specific job : Save the data (IPN) sent by the Paypal server to a file. What you put in the file is the IPN POST data itself to decode it "manualy" (a text editor for example) when available.
Currently IPNListener.aspx do its job : processing the IPN POST (and it should confirm the POST to the Paypal server).
I don't think you make it to troubleshoot ?
Yes, I know. But to troubleshoot you may create an another/additional page doing a specific job : Save the data (IPN) sent by the Paypal server to a file. What you put in the file is the IPN POST data itself to decode it "manualy" (a text editor for example) when available.
Currently IPNListener.aspx do its job : processing the IPN POST (and it should confirm the POST to the Paypal server).
I don't think you make it to troubleshoot ?
ASKER
Ok, so what you're saying is to have IPNListener.aspx write the received IPN post data to a file and look at the file later. Got it. No problem there. But troubleshooting could involve more than just looking at the IPN data received. There could be a problem parsing the data into variables, or storing the variables into the database. For this you'd like the script to be able to tell you what it's doing at various places, sort of like an Alert() call, or a Response.Write() to someplace I can look at.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ok. Got it! Thanks for the help Leakim. I'm closing out the question.
Steve
Steve
You're very welcome! Thanks a lot for the points!
POST /example.php HTTP/1.1
Host: example.com
Content-Type: text/html; charset=utf-8
Content-Length: length
name=John&surname=Neighbor
And response from the server would be:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: length
example.php script output
In case of GET request, request to the server would be:
POST /example.php?name=John&sur
Host: example.com
Content-Type: text/html; charset=utf-8
Content-Length: length
And same server response as above.
So I dont exactly know what you mean, but this could provide you the answer, what the communication between the http server and client browser is and see the background.