This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6827 - Resource retrieval: the same URI may be retrieved more than once
Summary: Resource retrieval: the same URI may be retrieved more than once
Status: RESOLVED FIXED
Alias: None
Product: mobileOK Basic checker
Classification: Unclassified
Component: Java Library (show other bugs)
Version: unspecified
Hardware: Other All
: P2 enhancement
Target Milestone: ---
Assignee: Abel Rionda
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-16 14:01 UTC by fd
Modified: 2009-04-30 15:49 UTC (History)
0 users

See Also:


Attachments

Description fd 2009-04-16 14:01:08 UTC
Description
-----
The same URI may appear more than once in the list of resources to retrieve, because they may appear in different contexts (typically image and object).

Although resource extractors try to re-use retrieval material as much as possible, two resources with the same URI may still have to be created with no retrieval information. The resources would both be retrieved, meaning that there will be two requests to the same URI.


TODO
-----
To ensure that URIs are retrieved only once, we may:
1. check that there exists retrieval information right before the retrieval process starts, but that would still leave open the possibility that the same URI are retrieved at once
2. introduce some kind of dependency between resources to postpone retrieval of a resource while a resource with the same URI is being retrieved and then re-use the retrieval material.
Comment 1 fd 2009-04-30 15:49:37 UTC
The Preprocessor now maintains a hashtable of the URIs (fragment section excepted) to retrieve associated with a reference resource. Resources are only processed when they are the reference resource or when the reference resource associated with their URI has been retrieved.

The Preprocessor.processResource method uses the retrieval information of the reference resource when available, and call Resource.retrieve if not.

This was previously being done by extractors, but did not quite fit there anyway so I removed this bit from the extractors implementations.