The question is, does it work with images? When I tried it (some time ago), it didn't work with inline images.. well I think it didn't, could you check please? multipart/replace *might* work with images. iframes would definitely work with images but require that we know the dimensions of the images in advance.
On Thursday 27 March 2008 17:33, freenetwork at web.de wrote: > > Matthew Toseland wrote: > > On Thursday 27 March 2008 01:16, you wrote: > > > >> * Michael Rogers <m.rogers at cs.ucl.ac.uk> [2008-03-26 09:36:32]: > >> > >> > >>> On Mar 25 2008, Matthew Toseland wrote: > >>> > >>>> Anyone got any better ideas? > >>>> > >>> Sorry if this would be impossible, I don't know anything about fproxy's > >>> internals, but when a key is requested, would it be possible to display a > >>> "please wait" page with a "cancel" button and/or a link to the main fproxy > >>> page, then redirect to the content once it's been fetched? > >>> > >> Sure it's possible... but not a realistic option. If the browser happens > >> to have reached its maximum amount of connections, I bet it won't obey > >> the "refresh" header we would set on the page we display, effectively > >> "breaking" the browsing. > >> > > > > Why would it be unrealistic? It wouldn't reach its maximum number of > > connections in the first place because connections wouldn't be blocked. > > > > > > IMHO the only sane solution. > I made some tests (Opera 9.26) with a refresh statement in the HTTP > Response header and they were cheering. > > - run " nc 127.0.0.1 -p 5555 -L" > - point browser to http://127.0.0.1:5555/ > - request can be seen in console > - send back this: > " > HTTP/1.1 200 Found > Refresh: 5 > Content-Type: text/plain > Content-Length: 10 > > Welcome... > " > - browser displays the stuff > - after 5 seconds the browser again requests the URL > - maybe this time the final content is returned, without the "Refresh" > > PRO: > - it does not use any HTML meta header, so we can send back "untampered" > content that get requestes after a certain amount > - therefore it might work on other content types as well, like images, etc. > - for every delivery a Content-Type can be set, so you can have e.g. 5 > HTML-pages saying "please wait" and after the file has been found it can > be e.g. an PDF > - if we know an image is requested, send an placeholder image (e.g. gif) > and let the browser retry later. then, after the final image has been > found, send the real image (e.g. jpg) > - the connection is like, never, open, and therefore not accounted from > the browser, making a connection limit meaningless > > DUNNO: > - do other browsers support this? > - does it work only on HTML or other file types as well? > > CONS: > - nuttin ;) > > > IMHO every tweaking with browser settings is fixing the symptons and is > very browser-specific. > If this works for every (supported) browser, we can ease everything :) > > > The tricky bit is images - if they can't be loaded immediately, we might have > > to convert them to iframes or something. Which means we'd have to know how > > big they are. But if there are no dimensions specified? > > multipart/x-mixed-replace maybe, but some browsers may not support it? > > > >>> It seems to me > >>> that people are opening lots of tabs, nothing is loading so they suspect > >>> Freenet has crashed, they try to open the stats page and when that fails > >>> > > it > > > >>> confirms their suspicion. So rather than changing Firefox, maybe we just > >>> need to give the user some feedback that Freenet is fetching the content > >>> and it hasn't crashed? > >>> > >> I don't think it's why people open loads of tabs... Freenet's latency > >> sucks hence "parallelizing" makes sense -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080327/37ff7dea/attachment.pgp>
