Transparentnejsi proxy cache?

[Lazo Igor]

> Tak tady premyslim o proxy cache systemech a napadla me takova vec:
> Podle me by slo naprogramovat, aby transparentni proxy cache davala sve
> pozadavky se skutecnou zdrojovou adresou tazatele. Samozrejme za
> predpokladu,
> ze je fyzicky umistena mezi prislusnymi dvema sitemi (treba ten-34 a
> okolni
> svet). Pak by se zmensily (ne-li odpadly) problemy s autentizaci
> IP-adresou.
> Pokud by se mi neco do browseru nenatahlo (resp. by se natahlo chybove
> hlaseni), dal bych Reload a squid (nebo cokoli jineho) by ten objekt
> stahl znovu, tentokrate s moji IP adresou.
>
> 	Jsou nekde slabiny tohoto pristupu?
>
Neznam http a tak nevim, zda se da poznat, ze
pozadavek na data je vysledkem akce Reload.
Asi ano, jinak by to cele nemelo smysl.
Pokud se tedy Reload da poznat:
- cache musi ustavit TCP spojeni s klientem
  ( asi se tedy bude vydavat za cilovy server )
- TCP spojeni obsahuje poradova a potvrzovaci
  cisla, ktera zacinaji nahodnym cislem a zvetsuji
  se primo umerne s poctem prenesenych bajtu
- v pripade snahy o prehozeni existujiciho
  TCP spojeni na cilovy server by tudiz
  s pravdepodobnosti hranicici s jistotou onen
  server poslal jine iniciacni poradove cislo
  TCP spojeni
- "srovnat krok" by bylo mozne jen prenesenim
  adekvatniho mnozstvi dat ( az 2na31 ) - takze
  takhle asi ne. Nebo pozadat o reset TCP
  spojeni, na coz ale vetsina implementaci TCP
  pry reaguje zrusenim tohoto spojeni ( coz je
  asi dost logicke )

Jinou moznosti by tedy bylo nechat projit kazde
TCP spojeni na cilovy server a sledovat ho s tim,
ze v pripade, ze pozadovana data jsou v cachi,
se spojeni prevezme a cilovy server se
odstrihne. Setrilo by to prenosove cesty a asi
i vykon ciloveho serveru ale asi by to nebylo
nejcistsi. Nevim jak by reagoval cilovy server
na spoustu "ustrizenych" spojeni. Chce to asi
jeste pouvazovat. Nemohlo by nekdy vadit, ze
si server mysli, ze se to nepreneslo, zatimco
klient je v pohode ?
Co na to znalci http, html, ASP apod. ?

S pozdravem

Igor Lazo