how to modify text in html form from python

[Mike Meyer]

"Philippe C. Martin" <pmartin at snakecard.com> writes:
> Mike Meyer wrote:
>> I don't know much about plugins.  I believe they get started when the
>> page loads, which gives you a chance to do the authentication when you
>> want it done.
> Well not in this case actually: the user triggers the plugin which in turn
> open the url, so the connection is "owned" by the plugin

I think we don't mean the same thing when we say "plugin". To me, a
plugin is a bit of code that gets executed when the page is rendered
to provide custom content with it's own behavior. Flash is probably
the most popular example. Like I said, I don't know much about
plugins, so they may be usable in other ways.

>> That won't work very well. HTML goes to the client to display. The
>> server can put data in hidden form elements that code running on the
>> client side can get to - and change - via the document object model
>> (DOM). However, the only way to send the changed data back to the
>> server is to get the client to submit the form. You can automate that,
>> but the results will be disconcerting to the user: they load a page,
>> and it reloads multiple times as the plugin exchanges data with the
>> server.
> Here again, I'm not dying for any page data to be visible: cannot the cgi
> script and the plugin do their business before that ?

Not if you're using plugin as defined above. Pretty much anything that
happens on the browser end is triggered by things happening in HTML -
which means it has to be displayed. I don't know of any way to
download something to the browser to run without rendering *something*
in the browser window - even if it's only a blank plage.

>> The problem with this is that the apache<->browser connection isn't
>> "a" connection, it's a series of HTTP request/repsonse
>> pairs. Originally, this implied tearing down and setting up a TCP
>> connection for every request. Modern software will leave the link open
>> and reuse it - but modern software also tends to have multiple
>> connetions open, so it can fetch images and other embedded objects in
>> parallel.
> I'm lost here, better do some more reading

HTTP is a stateless protocol. Every HTTP request goes the same: the
client sends a request saying what object it wants from the
server. The server reads the request, and sends back the response,
which is a collection of HTTP headers and a string of bytes. There's
lots more details invovled, and various things you can do to enhance
the performance of the system, but functionally they all boil down to
that.

>> You can make this work, but doing it like that requires making
>> multiple HTTP requests via the browser, which will be
>> disconcerting. I'd recommend taking the browser out of the loop. Have
>> the plugin talk directly to the server to do the
>> authentication. That's what the latest web buzzword (AJAX) does:
>> client-side software makes independent requests of the server (or
>> *any* server) to get data, and possibly updates the document the
>> browser is viewing as a result of that.
> Here I think it's OK as the plugin can "talk" to server prior to the browser
> showing anything.

If you say so. But certainly not through the browser.

>> So here's a scenario: the first cgi script gets info from the smart
>> card that puts it in a hidden form element and sends the page to the
>> browser. The plugin - started when the page loads - uses the DOM to
>> get that data, then makes an *independent* HTTP request to the server,
>> thus passing whatever it generated from the data in the form field to
>> a second cgi script. This happens several times, then the plugin
>> changes the HTML form to put whatever the cgi script generated into
>> the form, so that when the user finally submits the form, the third
>> cgi script - the one that handles the submitted form - sees the data
>> from the second script.
>> Actually, the exchanges between the plugin and the server don't need
>> to be HTTP requests. If you've got this working over some other TCP
>> protocol, there's no reason you can't keep doing it that way.
> Maybe that's my clue: can a cgi script, once triggered by a (let's say) POST
> request, use back and forth file transfer with the client ? through the
> _existing_ connection.

I honestly don't know. HTTP does a strict onetime turnaround - the
client sends, then the server sends, then you're done. There are hooks
in the protocol to allow a connection to be resused, but that's a
different request/response pair, and generally handled by the server,
not the cgi script. After all, the next request from the client may be
for some static file instead of the output of a cgi script.

Having a cgi script start two-way communications on the connection may
well work. But it won't be HTTP, and I wouldn't be at all surprised if
one or more of the components in some web connections - proxies,
caches, firewalls, etc. - choked on it. You're liable to get
apparently random failures depending on all kinds of exotic things.

           <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.