On Mon, 8 Apr 2002, Eli Marmor wrote:
> But as a developer of proxies, I also know quite well their > disadvantages, especially when they are transparent, without giving any > choice to the user, and when any type of site must pass them, no matter > if it uses things that are problematic for a proxy (in this message I > don't relate to reverse proxies, of course). > > I can count some main problems: > > 1. Many sites use non-standard HTTP things, that confuse proxies. this would indeed be a problem. however, the proxy is supposed to handle a client request saying 'no cache', and the browsers do implement it. if it doesn't work properly - this implies a bug in the browser or in the proxy. stating that this is a fundamental problem with proxies is ofcourse incorrect. a bug is something that should and can be fixed, and there's nothing about this kind of bug that should make it un-fixable. > 2. Many sites have a long delay in the middle of the response. In some > cases, proxies interpret delays as timeouts, and cancels the > transfer. stem of a bad configuration on account of the proxy. ofcourse, if your site has a 2 minutes delay during _initial_ transmision, that could be a problem, since proxies (and browsers) tend to wait a limited time until the _first_ chunk of reply is received, while they don't mind a long stale connection _after_ the first chunk of data. this limitation exists with the browsers too, so i don't see it solved by not using a proxy. for this reason, it was always the rule that if you have a long processing to do, first emit _something_, then do the long processing and then emit the rest of the reply. > 3. When you upload pages to a remote site, or modify a remote site, or > do any other remote maintenance of a site, you get the old content, > no matter how many reloads/refreshes/cache-clean/etc. you do. > Sometimes you can use HTTP headers to expire the page and uncache > it, but usually it is not possible. ofcourse, this is a sign of bugs in the proxy or browser, or missconfiguration. a proxy can be configured to not check the time update of data that was fetched in teh past X minutes. but it can also be configured to check the modification date on EACH request (using 'If-Modified-Since'). if its configured using this second method, then updating the pages on your remote web server will always make you receive the new page from the proxy - unless your remote web server has its time moving backwards (possiblewith daylight saving time changes, or someone manually modifying the OS's clock). there could be another problem, regarding synchronization of the clock of the proxy and the remoet web server. however, this can easily be solved, by making the proxy use the remote server's reported time as the 'last update' time of the page, and not using its own clock. then there should be no problem. > 4. Nobody wants to read old news, especially today in this country. > It is not so nice to read, a hour after a terror attack, that a > terror attack happened "a minute ago" (although professional sites > avoid such ambiguous language). this is the same as #3 above - so what if its someone ELSE that upadted the pages on the web server? its the same scenario, and hence the same solution. > P.S. I lost 2 hours, today, because of a transparent proxy. you mean, because of a _buggy_ proxy, or a badly configured proxy, or a buggy web server, or some such? -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
