>You're missing the point entirely, my friend. Stop and think about it for a
>moment: everything you have said is from the point of view of ME wanting to
>view MY updated web page. But I wrote that page for OTHERS to see... I am
>extremely happy (downright delighted) that roughly 1200 people have chosen
>to read my Sendmail SMTP AUTH HOWTO in the last three months, and I want to
>make the site better for them.
Yes. I do not disagree. But, you want to know that the pages are working as
you expect. It is extremely difficult to do that if you have to wait an hour
after making changes. It is hard to know that others see it correctly, if
you can't even see them.
>Transparent proxies where ISP's force their caches to keep things for too
>long so they can save bandwidth at the expense of their users getting the
>most recent data screws their users, not the website provider. In this
>case, I just happened to be both. Where my box is, who controls it, are all
>irrelevant. As Jason pointed out, even if the box were at my feet, by
>requesting "www.simpaticus.com" I would /STILL/ get their cached copy
>unless I also had split-horizon DNS installed in my house.
I'm curious, how does the ISP using a cache server save bandwidt? I can see it
if the requests are coming from their clients to web pages outside, but how
does it help when web page requests come from outside users to web pages that
are inside? The outside bandwidth is still used.
I'm still confused as to how any kind of DNS lookup is going to make a
difference in the routing of the HTTP packets. All DNS is for is to convert
the "www.simpaticus.com" into an actual IP address. At that point the box
then sends an HTTP request to that IP address. In my case, the IP addess
is the SAME box that the HTTP request from the browser is coming fro and
going to. Are you telling me that the Linux routing software will take that
IP request and send it to my ISP's router/gateway, only to have it returned
to me? Doesn't it make more sense that Linux routing would internally route
that request witin itself, never even placing the packets on my DSL circuit?
I would expect it to work the same way as it does when I use localhost in the
URL address (which is what I normally do anyway).
>Which again boils down to why I don't mind transparent proxies (it's a
>bitch to make money as an ISP), but it bugs the hell out of me to have
>their cache disregard a refresh request, especially when the page in
>question HAS changed and the cache doesn't even bother to go look (or
>worse, refuses to update anyway). Just not nice behavior there.
I do not disagree with ISPs trying to save money, but when a cahe proxy
works as badly as the one they are using, it has to hurt their customers.
If I were yuou, I'd be talking to their technical people right away to get
that problem fixed, because it is a problem.
MB
--
e-mail: vidiot@xxxxxxxxxx /~\ The ASCII
\ / Ribbon Campaign
[So it's true, scythe matters. Willow 5/12/03] X Against
Visit - URL: http://vidiot.com/ / \ HTML Email
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
