Forums

by Stephen Persson >> Tue, 24 Oct 2000 22:38:26 GMT

Hi,
How are people getting around Netscape issues within their web sessions. I have reimplemented the processRequest method on the WebSession class, but Netscape browsers don't give the correct httpString.
From the Jade help - "The httpString parameter is the string returned from a Web browser request as a result of a POST action on a Web page. When there is no POST action, the string that is returned is the same as the value returned by the queryString parameter."
This is true with IE browsers, but not so with Navigator. The httpString is always the same as the queryString.
How are people getting around this? Or is there any way around this?

Thanks
Stephen Persson

by Robert Barr >> Wed, 25 Oct 2000 1:00:02 GMT

I hadn't previously heard of anyone coming to grief over this - isn't
the form data still available in the queryString? Can you expand on the problem this causes you?

Rob

(BTW, this posting should be in one of the other JADE_TECH newsgroups, though not sure which one ... should there be a JADE_TECH_HELP newsgroup?)

by Stephen Persson >> Wed, 25 Oct 2000 2:56:38 GMT

No, the queryString only refers to the portion of the url after the ?
Eg, domain/directory/jadehttp.dll?WebPortal&param1&param2&....

The queryString is everything after the ? - WebPortal&param1&param2&....

The httpString should be parameters send back to the web server from a form, and are not shown in the url.
The queryString would then just be the app name, say, WebPortal, and the httpString would have all of the details of the form.
In our case this becomes a big issue because it is a site to purchase & deliver flowers online - and one of the details being passed back from the form is the credit card number. It is a secure site but none-the-less there is no way I want the credit card number appearing as part of the url. Secondly, there are form fields such as delivery details & card message which lets the user put in as much text as they want - urls have a finite length so there is no way you can pass this back as part of the queryString.

As I said this all works great with IE but the httpString from a Navigator request = queryString. Wrong.

Only if you use the GET instead of POST action on a form.

by Hido Hasimbegovic >> Thu, 26 Oct 2000 1:38:07 GMT

No, the queryString only refers to the portion of the url after the ? Eg, domain/directory/jadehttp.dll?WebPortal&param1&param2&....

The queryString is everything after the ? - WebPortal&param1&param2&....

The httpString should be parameters send back to the web server from a form, and are not shown in the url.

This is only the case if you use POST method in your form. GET method will display the whole HTTP query string in URL. Also, GET is limited to 512 chars (or thereabouts), which is the reason POST method is used for large forms. As far as I know this is in HTTP protocol specs ever since Mosaic days ... Are you sure you're using POST method from your form? Are you using any form validation code before form is submitted?

by Stephen Persson >> Thu, 26 Oct 2000 20:53:23 GMT

Yes - it is definitely the POST action and not GET for the very reasons you gave.
The html source for the form tag is:
<form method="post" enctype="text/plain" action="https://www.e-comservices.co.nz/webapps ... eeper&Chec kout" name="CreditCardDetails">

Yes there is a form validation method that is run prior to the page being submitted.

The form is also being submitted via a button (apparently it doesn't work if you try to submit a form using a picture as a button).

by Hido Hasimbegovic >> Thu, 26 Oct 2000 21:59:49 GMT

Action URL may well be the problem - you're mixing GET & POST by appending '&Checkout' to 'ShopKeeper' pipe name. Maybe Netscape gets confused by this & decides to default back to GET. Try burrying Checkout flag as a hidden field in your form (<INPUT NAME="Checkout" TYPE="hidden" VALUE="">). I had to use a similar trick to get XSL to append the pipe name to URL.
The reason I'm asking about entry validation is because of inconsistencies in JavaScript interpretation between IE and Netscape. Especially the small not-too-obvious ones.
Anyway, althought this isn't much, I hope it helps.

by Robert Barr >> Sun, 29 Oct 2000 20:40:44 GMT

You can use <input type=image name=myButton src="myButton.gif"> as an alternative to the plain gray browser-rendered button you get with
<input type=submit>. Slight difference in behaviour is that the browser returns the button position in the http string, so you need to take this into account when detecting the button has been pressed, e.g. &myButton.x=512&myButton.y=55&...

by Robert Barr >> Sun, 29 Oct 2000 21:00:11 GMT

Yes there is a form validation method that is run prior to the page being submitted.

A small philosphical point, and design tip for new players ... browser side validation should be avoided for anything of a 'serious' or
'secure' nature, as the validation code can potentially be modified and bypassed, so the validation must be repeated on the server anyway
(though I accept there are times where browser validation is desirable).

It's also important when designing a web (or any other user) interface
to design for prevalidation where possible. That is, don't give the user the option of getting it wrong by using listboxes, checkboxes and optionboxes to allow the user to give valid responses only. Common examples are asking a user to enter a free-form date (day, month, year should be selected from pre-populated listboxes).

(This all apart from the fact that client-side scripting is so hard if you support multiple browsers - what do users do with little gray
dialogs saying "Error in script at line 10. Debug"?).

by Stephen Persson >> Sun, 29 Oct 2000 21:43:30 GMT

No unfortunately this didn't work either - I removed the &Checkout parameter but was still left with the same problem.
The WebSession window showed the following :
After request from an IE Browser:
30 October 2000, 10:10:05 Query String = ShopKeeper
30 October 2000, 10:10:05 Http String = Merchant=7574948
Buyer=37
Name=fghgfdgfh
Email=
StreetNumber=
StreetName= And all the rest........

After request from a Navigator browser with the same page:
30 October 2000, 10:15:40 Query String = ShopKeeper
30 October 2000, 10:15:40 Http String = ShopKeeper

by Robert Barr >> Mon, 30 Oct 2000 1:00:24 GMT

No unfortunately this didn't work either - I removed the &Checkout parameter but was still left with the same problem.

"<form action=" should specify a file, but if Netscape doesn't tolerate parameters, then try removing ShopKeeper too (it's the first parameter after the file name).