Okay, replying to myself and topposting... *hands some spears* I made a test and simply replaced the mimetype with "image/gif", so the "image" is broken but the browser still thinks it's an image and hopefully behaves normal. My Opera 9.23 sends a new request after 5 seconds, so from my side it seems to work with binary based mimetypes.
freenetwork at web.de wrote: > 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, 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 >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Devl mailing list >>>>> Devl at freenetproject.org >>>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >>>>> > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >
