[WEB4LIB] RE: web cache and remote access

[Brian Kelly]

Hi
   This is a well-known problem in the Library community.  Within the UK
Higher Education community we have a well-developed caching
infrastructure - developed to reduce the costs of network bandwidth
especially to the US.
  Caches are a *good thing*  in my opinion.  Rather than fight against
them I'd suggest you need to look into other types of authentication.
   We have a mailing list in the UK which disucsses such issues, from a
library / techie perspective.  The list archives are available at
http://www.mailbase.ac.uk/lists/authentication/
   There's not been much traffic, but some of the messages may be of
interest.
   Brian Kelly
--------------------------------------------------------------------
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email:  b.kelly at ukoln.ac.uk     URL:    http://www.ukoln.ac.uk/
Homepage: http://www.ukoln.ac.uk/ukoln/staff/b.kelly.html
Phone:  01225 323943            FAX:   01225 826838
--------------------------------------------------------------------
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email:  b.kelly at ukoln.ac.uk     URL:    http://www.ukoln.ac.uk/
Homepage: http://www.ukoln.ac.uk/ukoln/staff/b.kelly.html
Phone:  01225 323943            FAX:   01225 826838
----- Original Message -----
From: "Bryan H. Davidson" <bdavidso at comp.uark.edu>
To: "Multiple recipients of list" <web4lib at webjunction.org>
Sent: Wednesday, May 31, 2000 7:45 PM
Subject: [WEB4LIB] RE: web cache and remote access


> All -
>
> I would first like to thank all of you who replied to the original
posting
> concerning web caching and remote access.
> This has really brought to light the larger issue of web caching
servers in
> general.  After speaking to some folks in computing services on our
end, it
> seems that, even if the caching server was not in place in Little
Rock,
> chances are that one's request is being answered by a caching server
> somewhere else on the net anyway, rather than the actual live
"source".  At
> least that is my understanding?
>
> In our situation, the only reason this was brought to light in the
first
> place was that this particular caching server in Little Rock also has
some
> proxy / firewall functionality that distorts our IP.
>
> Most computing services people do not seem to think that this is a
tragedy,
> and most accept this as a common practice that will be an overall
benefit to
> users.
>
> Mr. Lansky brings up an interesting point though. -- I'll quote his
previous
> posting:
> "...this will mean something for us as legal pages change
frequently--such
> things as rules of courts, etc.  we don't want the attorney to look at
an
> old page on their machine when actually there is a more current
version on
> the web."
>
> What are the implications of web caching and the information
profession?
>
> As an update to our current situation, I just forwarded a list of
about 100
> publishers that provide us with access to e-journal titles on IP
> authentication. All of which somebody in Little Rock will have to key
in to
> the exception list by hand.  I think that this will be one means of
getting
> the IP issue resolved, especially when every library in the state
begins to
> make the same requests.
>
> We cannot, unfortunately, as some of you suggested, simply add the IP
range
> of the caching server to the list we provide our vendors with. Since
an
> entire network of libraries must go through this one pipe / server, it
seems
> that all would be granted access to those databases.
>
> I also passed along Dan's solution, of simply asking DIS not to cache
> anything with a referrer of
> library.uark.edu/*.  For some reason, they say this will not work.
I'll keep
> everybody posted as I am still pressing for an better answer than
"just
> because".  Again, I think that they will be receiving an education as
to
> exactly what it is libraries "do" once they realize how frequently we
and
> other libraries add and modify links to IP authenticated resources,
which
> DIS now has to do to also, in order for us get IP authentication to
work.
>
> Bryan
>
> ----- Original Message -----
> From: "Lansky, Yale M. (NYC)" <LANSKYY at JacksonLewis.com>
> To: "Multiple recipients of list" <web4lib at webjunction.org>
> Sent: Wednesday, May 31, 2000 1:07 PM
> Subject: [WEB4LIB] RE: web cache and remote access
>
>
> > I forwarded this original message to my MIS guru, who sent me the
reply
> > below.  I have also included my original message to him when I
forwarded
> the
> > message which begins to explain my question/problem.
> >
> > As you can see, despite trying to set up Internet Explorer to get
the
> newest
> > page from the server, I am still concerned that my users are
actually
> seeing
> > the page that is stored on their hard drive and not the latest page
from
> the
> > server.  I am concerned about this because if one of my users relies
upon
> a
> > document from the web, which is actually being viewed from the
cache, they
> > may not be getting the most current information available which is
> essential
> > in most cases.
> >
> > As you can see from my MIS person, the problem actually seems to lie
with
> > the servers.  Does anyone have any further information about this?
How do
> > we insure that our users are getting the most up to date information
> without
> > cleaning out their temporary internet files on a regular basis?  I
have
> told
> > people to hit the refresh or reload buttons, but based upon some
testing
> > with pages I am developing, this is not always a fool proof solution
> either.
> > I have had the same page display, even though refresh was pushed. (I
had
> to
> > close the browser and relaunch for the newest page to be displayed.)
> >
> > I am also aware that in Netscape you can view the expiration and
created
> > date by choosing Page Info from the View menu.  However, I have
never
> found
> > a comparable feature in Internet Explorer. Have you?
> >
> > I look forward to your thoughts.
> >
> >
> > Yale M. Lansky--Electronic Services Librarian
> > Jackson Lewis Schnitzler & Krupman
> > New York, New York
> > 212-545-4058 Fax: 212-687-0228
> > LanskyY at jacksonlewis.com
> > http://www.jacksonlewis.com
> >
> > > Jackson Lewis is dedicated exclusively to representing employers
in
> > the practice of employment, labor, benefits and immigration law and
> related
> > litigation.
> > >
> > Confidentiality Note:  This e-mail, and any attachment to it,
> > contains privileged and confidential information intended only for
the use
> > of the individual(s) or entity named on the e-mail.  If the reader
of this
> > e-mail is not the intended recipient, or the employee or agent
responsible
> > for delivering it to the intended recipient, you are hereby notified
that
> > reading it is strictly prohibited.  If you have received this e-mail
in
> > error, please immediately return it to the sender and delete it from
your
> > system.  Thank you.
> >
> >
> >
> > -----Original Message-----
> > From: Hrncir, Garrett (DAL)
> > Sent: Wednesday, May 31, 2000 1:24 PM
> > To: Lansky, Yale M. (NYC)
> > Subject: RE: [WEB4LIB] web cache and remote access
> >
> >
> > Sounds like there proxy server is not set up correctly. It is
interesting.
> >
> > The easiest way to get the pages to refresh correctly is to set an
expire
> > date in the metatags, this is what the browser looks for when it
decides
> > whether to get the page or to use the cached version. If the cached
> version
> > has not expired yet it will serve it. If there is no expired date (I
am a
> > little sketchy on this but I believe this is correct), the browser
goes to
> > the web site and checks the modified date. If it is newer than the
one in
> > the cache it gets it, otherwise it uses the one in the cache. The
reason
> you
> > sometimes have problems is that not all web servers report the time
the
> page
> > was last modified or if the page was modified on the same day the
time
> could
> > be off causing the browser to think that the page in the cache is
the same
> > or newer, etc.
> >
> > That setting in explorer just means check for a newer version, not
get a
> > newer version, if the server is not set up correctly you will never
get
> the
> > newer pages.
> >
> > -----Original Message-----
> > From: Lansky, Yale M. (NYC)
> > Sent: Tuesday, May 30, 2000 4:28 PM
> > To: Hrncir, Garrett (DAL)
> > Subject: FW: [WEB4LIB] web cache and remote access
> >
> >
> > We don't have to worry about this yet, but it is interesting.  We
have
> this
> > problem locally when people look at a page in the cache (temp int
files)
> and
> > they are not seeing the most up to date page even though IE is set
to get
> > the page fresh each time. (never can seem to get it to work)  once
people
> > use the net more this will mean something for us as legal pages
change
> > frequently--such things as rules of courts, etc.  we don't want the
> attorney
> > to look at an old page on their machine when actually there is a
more
> > current version on the web.
> >
> >
> > -----Original Message-----
> > From: Bryan H. Davidson [mailto:bdavidso at comp.uark.edu]
> > Sent: Tuesday, May 30, 2000 4:43 PM
> > To: Multiple recipients of list
> > Subject: [WEB4LIB] web cache and remote access
> >
> >
> > Greetings -
> >
> > Here at the University of Arkansas, Fayetteville, we have recently
> > encountered a serious problem with remote access to our online
databases
> > that authenticate by our campus IP address. I would be very
interested in
> > hearing whether other institutions or libraries have encountered a
similar
> > problem.
> >
> > The Problem:
> >
> > All of our Internet traffic, as well as most of the libraries'
Internet
> > traffic in the state, travels through a server in Little Rock before
going
> > out into the world (and that is another story).  This in itself has
not
> been
> > a major problem until now.
> >
> > This weekend, they implemented something to the effect of  a "web
caching
> > server" without any notification. As a result we immediately lost
access
> to
> > all of our subscription online resources that authenticate by IP,
because
> > the server altered the IP number. Once we figured out that this was
the
> > cause of the problem, they had to add the URL of each database to an
> > "exception list" on the server. As a result, not only did we spend
hours
> > scanning through all of our major vendors URLs to get them added to
the
> > exception list, but we are now in the process of going through all
of the
> > URLs for the individual ejournal titles that we subscribe to through
> > different publishers (about 50 right now).
> >
> > This implies that every time we acquire a new e-journal from a
different
> > vendor, purchase access to a new database, or even want to set up a
> database
> > trial, that we will have to contact DIS in Little Rock to have this
URL
> > added to the exception list. As you might expect, the needs of the
library
> > are not at the top of their list and as a result, they are not very
quick
> > about making the necessary changes to the exception list.
> >
> > Their argument:
> > They argue that 80% of web page requests are for static pages. The
web
> > caching system is therefor supposed to increase network speed by
serving
> up
> > a cached version of that page the next time it is requested, thus
reducing
> > network traffic.
> >
> > It seems to me that, for most libraries, the opposite is true -  80%
or
> more
> > of a libraries' Internet activity goes to online subscription
databases
> > where users perform dynamic, unique searches every time.  Even as I
type I
> > am getting calls from our users who are being prompted for passwords
where
> > they should be authenticated by IP.
> >
> > Has anyone else encountered this problem. Should it even be a
problem?
> >
> > Much Thanks
> >
> > ~~~~~~~~~~~~~~~~~~~~~
> > Bryan H. Davidson
> > Electronic Products Librarian / Webmaster
> > University of Arkansas Libraries, Fayetteville
> > Ph. 501-575-4665
> >
>
>