Re: limiting access

Bill,

Sorry for the confusion. I think you misunderstood. We were 
discussing the use of a Conditional request using a HEAD versus 
using a GET. Both will return a code instead of data if the data is 
unchanged (304, in the case of the GET). The slight performance hit 
with the HEAD is the fact that if the data *has* changed, then the 
GET must be performed whereas with the GET, if the data has changed, 
you just start getting the data.

In either of these two cases, unchanged data is not sent.

I agree with your sentiments about the trivial amount of coding 
necessary to implement. I had this working in my aggregator the same 
day that someone pointed me to the HTTP specifications. I googled 
the header name and found a page that described how to do it.

Easy!






--- In [email protected], "Bill Kearney" <ml_yahoo@i...> wrote:
> > Yes, fair enough. Using conditionals in HEAD requests is
> > unnecessarily conservative if you expect and want to download the
> > latest. It would be less efficient to make two requests.
> 
> Less efficient how?  In that the request process would be two hits 
if the
> content was known to be completely changing?  Yes, perhaps it 
might.  But
> for the great many feeds we watch via Syndic8 the number that 
don't change
> as frequently as many aggregators default to using is 
considerable.  It
> would be of GREAT savings on both ends to use both HEAD requests 
and conneg
> headers.  Make the request based on what you know and let the 
server
> likewise make educated decisions about what to deliver.  If the 
server's
> known to accept and correctly used header negotiation then a HEAD 
request
> wouldn't be needed.  Trouble is it's difficult know which ones do 
and which
> ones don't.  Erring on the side of conservation seems like a 
reasonably good
> idea.
> 
> > The potential saving on the content body is not significant 
unless you're
> > checking thousands of feeds which are not updated as often as 
they
> > claim to be!
> 
> Or if you're the feed source and you're getting beat up by 
countless
> individual aggregators all with too-short a retry interval.
> 
> This isn't to argue that anyone's wrong here.  More thar arguments 
about
> savings or waste based on lightening the load of the programmer 
making the
> aggregator are perhaps falsely economic.  It's far better to make 
the
> developer of an aggregator put forth the rather trivial amount of 
effort to
> track the data and make informed requests of the source than to 
turn loose
> more crappy software that crucifies the feed servers needlessly.
> 
> Yes, it will take the developer a little more time to write the 
code to
> store the last change data and use it when making subsequent 
requests for
> the feed.  It might likewise make a little more work for the feed 
provider
> if they're generating the feed from a dynamic script.  It can help 
make the
> transfer more efficient to serve up only the items detected from 
the
> requested date.  For someone using most blog software that renders 
to static
> files they need do nothing to their server.  The savings, however, 
when
> things start scaling up can be significant.  Especially for the 
small site
> faced with sudden uptake of it's feed.  But even for the heavily 
used sites
> it's worth considering.
> 
> -Bill Kearney
> Syndic8.com








 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rss-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/