Editing Persistent uniform resource locator (section)

==Redirection of URL fragments ==
The PURL service includes a concept known as partial redirection. If a request does not match a PURL exactly, the requested URL is checked to determine if some contiguous front portion of the PURL string matches a registered PURL. If so, a redirection occurs with the remainder of the requested URL appended to the target URL. For example, consider a PURL with a URL of <code><nowiki>http//purl.org/some/path/</nowiki></code> with a target URL of <code><nowiki>http://example.com/another/path/</nowiki></code>. An attempt to perform an HTTP GET operation on the URL <code><nowiki>http//purl.org/some/path/and/some/more/data</nowiki></code> would result in a partial redirection to <code><nowiki>http://example.com/another/path/and/some/more/data</nowiki></code>. The concept of partial redirection allows hierarchies of Web-based resources to be addressed via PURLs without each resource requiring its own PURL. One PURL is sufficient to serve as a top-level node for a hierarchy on a single target server. The new PURL service uses the type "partial" to denote a PURL that performs partial redirection.

Partial redirections at the level of a URL path do not violate common interpretations of the HTTP 1.1 specification. However, the handling of URL fragments across redirections has not been standardized and a consensus has not yet emerged. [[Fragment identifier]]s indicate a pointer to more specific information within a resource and are designated as following a <code>#</code> separator in URIs.<ref>{{Cite IETF |section=1.2.3 |title=Uniform Resource Identifier (URI): Generic Syntax |rfc=3986 |std=66 |date=January 2005 |access-date=2008-03-01 |publisher=[[IETF]] Networking Working Group|doi=10.17487/RFC3986 |last1=Berners-Lee |first1=T. |last2=Fielding |first2=R. |last3=Masinter |first3=L. |s2cid=30973664 }}</ref>

Partial redirection in the presence of a fragment identifier is problematic because two conflicting interpretations are possible.<ref>{{Cite web |url=http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt |title=Handling of Fragment Identifiers in Redirected URLs, Expired Internet Draft |date=1999-06-30 |access-date=2008-03-01 |publisher=[[IETF]] Networking Working Group}}</ref> If a fragment is attached to a PURL of type "partial", it is unclear whether a PURL service should assume that the fragment has meaning on the target URL, or discard it in the presumption that a resource with a changed location may have also changed content, thus invalidating fragments defined earlier. Bos suggested that fragments should be retained and passed through to target URLs during HTTP redirections resulting in 300 (Multiple Choice), 301 (Moved Permanently), 302 (Found) or 303 (See Other) responses unless a designated target URL already includes a fragment identifier. If a fragment identifier is already present in a target URL, any fragment in the original URL should be abandoned. Bos' suggestion failed to navigate the IETF standards track and expired without further work. Dubost ''et al.'' resurrected Bos' suggestions in a W3C Note (not a standard, but guidance in the absence of a standard).<ref name="Dubost">{{Cite web |url=http://www.w3.org/TR/2001/NOTE-cuap-20010206#uri |title=Common User Agent Problems, W3C Note |date=2001-02-06 |access-date=2008-03-01 |publisher=[[World Wide Web Consortium]]}}</ref>  Makers of Web clients such as browsers have "generally"<ref name="Dubost" /> failed to follow Bos' guidance.

Starting with PURLz 1.0 series, the PURL service implements partial redirections inclusive of fragment identifiers by writing fragments onto target URLs in an attempt to comply with<ref name="Dubost"/> and avoid problematic and inconsistent behavior by browser vendors.