- From: Sean Owen <srowen@google.com>
- Date: Tue, 23 Oct 2007 14:56:50 -0400
- 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 UTC