cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: problems on communicating with a banks server

From: Tim <tchemaly_at_ing.sun.ac.za>
Date: Wed, 9 Aug 2000 22:43:28 +0200

Hi Nico
I guess some things just don't work...even though I gave the bank's servers
my wrong account details the headers I received was still
HTTP/1.1 200 OK

Unfortunately I did not write the software on the server and have now
control over it..I'm only using it.

Guess I will have to check the contents of the page?
Thanks
Tim

----- Original Message -----
From: <Nico.Baggus_at_mail.ing.nl>
To: <curl_at_contactor.se>
Sent: 08 August 2000 04:01
Subject: RE: problems on communicating with a banks server

> Hi,
>
> You have two ways you can pass information back to the user:
>
> 1) the return status of the form: it is in the HTTP header sent to you
> as a reply to the GET/PUT/POST/HEAD etc. request.
> it is the second word on the firstline of a reply.
>
> Like: HTTP/1.1 200 OK
> or: HTTP/1.1 401 Authorisation required
>
> 2) in the contents of a page. And that has to be strictly defined
> to be of use.
>
> 3) You can use a form as a reply (#2) and add some (hidden) fields on it
> then you have some means of HTML structured answers.
>
> For the number 2 and 3 to work you need control over (part of) the page
> that is sent to the user as a reply.
>
> For the number 1 option you need control over the CGI-scripts as they
should
> return
> some statuscode (That is within specs of HTTP).
>
> The HTTP Protocol & HTML Langage were defined for human use.....
> and now we are trying to automate talking to an interface designed
> for humans, free layout, free text (free everything ;-).
> Personaly I believe it will become a nightmare in this way.
>
> Do you have a posibility to define some other protocol (you can use SSL
> even then) and handle transaction without the (in this case) hassle of
> HTTP & HTML. In other words, Roll-Your-Own.
> Then you are in total control.
>
> (Are you the designer/builder of the interface or the victim of
> an existing interface that is fed to/forced upon you)
>
>
> I Hope this helps,
>
> Nico Baggus
>
> >-----Original Message-----
> >From: curl_at_contactor.se
> >Sent: Tuesday, August 08, 2000 11:55 AM
> >To: curl_at_contactor.se
> >Subject: Re: problems on communicating with a banks server
> >
> >
> >Hi Nico
> >
> >Is there any way I can check for some kind of code from the
> >banks' server to
> >see whether the process was successfull?. As I've said,
> >checking for a text
> >string like "The account nr is not the required length" is not
> >the best of
> >ways to check for feedback.
> >Thanks
> >Tim
> >
> >----- Original Message -----
> >From: "Nico Baggus" <nico_baggus_at_compuserve.com>
> >To: <curl_at_contactor.se>
> >Sent: 08 August 2000 12:34
> >Subject: RE: problems on communicating with a banks server
> >
> >
> >> Hi,
> >>
> >> I have more or less the same problem.
> >> The processing of a post might invoke timeouts if
> >> responces are kept waiting too long.
> >> So I have to start to report a page with 200 back
> >> to tell something was correctly received.
> >> Later on I use some strict codes
> >> like
> >> ==>OK and
> >> ==>ERRORS and
> >> ==>WARNINGS
> >> followed by ---<original text lines>
> >>
> >> if something happens.
> >>
> >> These come in <PRE> </PRE> blocks....
> >> (so no special HTML layout is needed to send error messages.
> >(In this case
> >> I'm on the Publishers side of things).
> >>
> >> Just waiting for all processing to complete and answer
> >> the final status as a 200 or different HTTP error code might
> >just take too
> >> long. (as it is about uploading & processing files).
> >>
> >> This ==> and --- signaling is done by the CGI
> >> processing around the uploads, and "applications" are
> >> generaly ignorant about being run within the
> >> cgi script. (The can also be run from a commandline
> >> if needed.)
> >>
> >>
> >> regards,
> >> Nico Baggus
> >>
> >>
> >
> >
>
>
> PLEASE NOTE:
> The information contained in this electronic mail message is
> privileged and confidential, and is intended only for use of the
> addressee. If you are not the intended recipient, you are hereby
> notified that any disclosure, reproduction, distribution or other
> use of this communication is strictly prohibited.
> If you have received this communication in error, please notify
> the sender by reply transmission and delete the message without
> copying or disclosing it.
Received on 2000-08-09