Sorry, I don't have a capable HTTP framework to return binary data. I'm limited to console commands...
PS: "Refresh"s upon a 301 redirect don't seem to work here. Matthew Toseland wrote: > 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, [EMAIL PROTECTED] wrote: > >> Matthew Toseland wrote: >> >>> On Thursday 27 March 2008 01:16, you wrote: >>> >>> >>>> * Michael Rogers <[EMAIL PROTECTED]> [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 >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Devl mailing list >>>> Devl@freenetproject.org >>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
