W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > October 2007

Re: Using HEAD rather than GET

From: Sean Owen <srowen@google.com>
Date: Tue, 23 Oct 2007 14:56:50 -0400
Message-ID: <e920a71c0710231156w2e534c48n75a8918ec91aa266@mail.gmail.com>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: public-mobileok-checker <public-mobileok-checker@w3.org>

I had specifically argued that we should always use GET even when HEAD
is possible since we want to test real-world behavior, and browsers
will be issuing GETs, and I can imagine some content doing different
or funny things on a HEAD.

If it really is a performance problem, I think we can start by making
sure the body is not even retrieved on a GET.


On 10/23/07, Dominique Hazael-Massieux <dom@w3.org> wrote:
>
> Hi,
>
> >From what I can see in the current code, it seems we're using HTTP GET
> for all our checks for external resources; there are quite a few cases
> where a HTTP HEAD would be sufficient:
> * embedded resources (style sheets, images, objects) whose content-type
> is not in the DDC
> * linked resources (in LINK_TARGET_FORMAT) where we really only care
> about the content type
>
> In practice, this probably means always start with a HEAD (except on the
> primary document), and only do a GET when the context and the
> content-type justifies it.
>
> This would certainly help in terms of performance, and make it more
> likely that we can use the library even on links-heavy pages.
>
> Unfortunately, the behavior seems to pretty down in the stack of the
> code, and I don't think my limited Java abilities would allow me to make
> such a refactoring - anyone volunteering?
>
> Dom
>
>
>
>
Received on Tuesday, 23 October 2007 18:57:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:04 GMT