Mike, Again, thanks.
By plugin I mean the browsers' extensions: ex: http://roachfiend.com/archives/2004/12/08/how-to-create-firefox-extensions/#more-4. IE has the same type or resorts also to activeX components. Right now I know how to program that guy to open a url.... I guess I need to some thinking before I ask more questions. Regards, Philippe Mike Meyer wrote: > "Philippe C. Martin" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list