Paul Gilmartin writes: > On Nov 29, 2008, at 02:34, David Woolley wrote: [...] > > Most browsers would give up after just a few minutes! > > > > I believe there is an HTTP response (Status 100???) which allows > > one to say "please wait". If that's right and Lynx supports it, a > > better approach would be to have the application periodically send > > that response. > > > Dries may not have control over the server which would allow > him to do this. But if the CGI is named "nph-"whatever.CGI, > he may be able to assert some control over the responses > returned by the server, and even their timing. > > Do browsers manifest the "please wait" response to the human > viewer? I have a similar problem; I don't know about timeout, > but while a process that may take a couple minutes runs I > issue in the HTML a blip line every few seconds to show that > the process hasn't died. Is there a better way?
The way I read RFC2616, the "100 continue" response has nothing to do with notifying users of timeouts, it is intended to separate, for example, a "POST" request from a very large request body, so that the body doesn't get transmitted if the server rejects the request; the client must ask for the "100" response (with "Expect: 100-continue"), otherwise the server will just wait for the request body; the RFC also says "Unexpected 1xx status responses MAY be ignored by a user agent", which implies that they aren't required to display a "please wait" message. If you have control on the server side, the best way could be to have two requests: one to start processing, and the other to see if there are results. This way you don't have timeouts, and any network problems during the request aren't likely to stop things from working. The first request could return some form of ID token (or a temporary file name) so the second request can ask for the right set of results. C _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev
