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

Reply via email to