当相对URI包含空路径时,Java的URI.resolve与RFC 3986不兼容吗?

前端之家收集整理的这篇文章主要介绍了当相对URI包含空路径时,Java的URI.resolve与RFC 3986不兼容吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我相信 Java的URI.resolve方法的定义和实现与 RFC 3986 section 5.2.2不兼容.我知道Java API定义了该方法的工作原理,如果现在改变它会破坏现有的应用程序,但我的问题是:任何人都可以确认我的理解是这种方法与RFC 3986不兼容?

我正在使用这个问题的例子:java.net.URI resolve against only query string,我将在这里复制:

我正在使用JDK java.net.URI来构建URI.
我想附加到一个绝对的URI对象,一个查询(在String中).例如:

  1. URI base = new URI("http://example.com/something/more/long");
  2. String queryString = "query=http://local:282/rand&action=aaaa";
  3. URI query = new URI(null,null,queryString,null);
  4. URI result = base.resolve(query);

理论(或我认为的)是这样的决心应该返回:

  1. http://example.com/something/more/long?query=http://local:282/rand&action=aaaa

但是我得到的是:

  1. http://example.com/something/more/?query=http://local:282/rand&action=aaaa

我对RFC 3986 section 5.2.2的理解是,如果相对URI的路径为空,则使用基本URI的整个路径:

  1. if (R.path == "") then
  2. T.path = Base.path;
  3. if defined(R.query) then
  4. T.query = R.query;
  5. else
  6. T.query = Base.query;
  7. endif;

并且只有指定路径是要与基本路径合并的相对路径:

  1. else
  2. if (R.path starts-with "/") then
  3. T.path = remove_dot_segments(R.path);
  4. else
  5. T.path = merge(Base.path,R.path);
  6. T.path = remove_dot_segments(T.path);
  7. endif;
  8. T.query = R.query;
  9. endif;

但Java实现始终执行合并,即使路径为空:

  1. String cp = (child.path == null) ? "" : child.path;
  2. if ((cp.length() > 0) && (cp.charAt(0) == '/')) {
  3. // 5.2 (5): Child path is absolute
  4. ru.path = child.path;
  5. } else {
  6. // 5.2 (6): Resolve relative path
  7. ru.path = resolvePath(base.path,cp,base.isAbsolute());
  8. }

如果我的阅读是正确的,要从RFC伪代码获取此行为,您可以在查询字符串之前将一个点作为相对URI中的路径,从我使用相对URI作为网页链接的经验来看,是我期望的:

  1. transform(Base="http://example.com/something/more/long",R=".?query")
  2. => T="http://example.com/something/more/?query"

但是我会期望在一个网页上,页面http://example.com/something/more/long”到“查询”的链接将转到“http://example.com/something/more/long?query”,而不是“http://example.com/something/more/?query” – 换句话说,与RFC一致,但不是与Java实现.

我的阅读RFC是否正确,Java方法与它不一致,还是我错过了什么?

解决方法

是的,我同意URI.resolve(URI)方法与RFC 3986不兼容.原来的问题本身就提供了大量的研究,有助于这个结论.首先,让我们清除任何混乱.

如Raedwald所解释的(在现在删除的答案中),以/结尾或不以/结尾的基本路径有区别:

> fizz相对于/ foo / bar是:/ foo / fizz
> fizz相对于/ foo / bar /是:/ foo / bar / fizz

虽然正确,但这不是一个完整的答案,因为原来的问题不是询问一个path(即上面的“fizz”).相反,该问题涉及相对URI引用的单独的query component. URI类constructor used in the example code接受五个不同的String参数,除了queryString参数之外的所有参数都被传递为空. (请注意,Java接受一个空字符串作为路径参数,这在逻辑上会导致一个“空”路径组件,因为“the path component is never undefined”虽然它是“may be empty (zero length)”.)这将在以后很重要.

earlier comment年,Sajan Chandran指出,java.net.URI class被记录为实现RFC 2396,而不是RFC 3986的问题.前者在2005年被后者废弃了.URI类Javadoc没有提到新的RFC可以被解释作为其不兼容的更多证据.我们再多一点:

> JDK-6791060是一个开放的问题,建议这个类“应该更新为RFC 3986”.那里的一个评论警告说,“RFC3986并没有完全倒退
兼容2396“.
>以前尝试将URI类的部分更新为符合RFC 3986(例如JDK-6348622),但是后来的兼容性为rolled back. (另见JDK邮件列表中的this discussion)
>尽管路径“合并”逻辑听起来相似,如noted by SubOptimal所示,较新的RFC中指定的伪代码actual implementation不匹配.在伪代码中,当相对URI的路径为空时,生成的目标路径按原样复制基本URI.在这些条件下不执行“合并”逻辑.与该规范相反,Java的URI实现修剪了最后一个字符之后的基本路径,如问题所述.

如果您想要RFC 3986行为,则可以使用URI类的替代方法. Java EE 6实现提供javax.ws.rs.core.UriBuilder,(在泽西1.18)似乎按照预期的行为(见下文).至少就RFC的编码而言,就编码不同URI组件而言至关重要.

在J2EE之外,Spring 3.0引入了UriUtils,具体记录了“基于RFC 3986的编码和解码”. Spring 3.1不推荐使用其中的一些功能,并引入了UriComponentsBuilder,但是它不符合任何特定的RFC,不幸的是.

测试程序,展示不同的行为:

  1. import java.net.*;
  2. import java.util.*;
  3. import java.util.function.*;
  4. import javax.ws.rs.core.UriBuilder; // using Jersey 1.18
  5.  
  6. public class StackOverflow22203111 {
  7.  
  8. private URI withResolveURI(URI base,String targetQuery) {
  9. URI reference = queryOnlyURI(targetQuery);
  10. return base.resolve(reference);
  11. }
  12.  
  13. private URI withUriBuilderReplaceQuery(URI base,String targetQuery) {
  14. UriBuilder builder = UriBuilder.fromUri(base);
  15. return builder.replaceQuery(targetQuery).build();
  16. }
  17.  
  18. private URI withUriBuilderMergeURI(URI base,String targetQuery) {
  19. URI reference = queryOnlyURI(targetQuery);
  20. UriBuilder builder = UriBuilder.fromUri(base);
  21. return builder.uri(reference).build();
  22. }
  23.  
  24. public static void main(String... args) throws Exception {
  25.  
  26. final URI base = new URI("http://example.com/something/more/long");
  27. final String queryString = "query=http://local:282/rand&action=aaaa";
  28. final String expected =
  29. "http://example.com/something/more/long?query=http://local:282/rand&action=aaaa";
  30.  
  31. StackOverflow22203111 test = new StackOverflow22203111();
  32. Map<String,BiFunction<URI,String,URI>> strategies = new LinkedHashMap<>();
  33. strategies.put("URI.resolve(URI)",test::withResolveURI);
  34. strategies.put("UriBuilder.replaceQuery(String)",test::withUriBuilderReplaceQuery);
  35. strategies.put("UriBuilder.uri(URI)",test::withUriBuilderMergeURI);
  36.  
  37. strategies.forEach((name,method) -> {
  38. System.out.println(name);
  39. URI result = method.apply(base,queryString);
  40. if (expected.equals(result.toString())) {
  41. System.out.println(" MATCHES: " + result);
  42. }
  43. else {
  44. System.out.println(" EXPECTED: " + expected);
  45. System.out.println(" but WAS: " + result);
  46. }
  47. });
  48. }
  49.  
  50. private URI queryOnlyURI(String queryString)
  51. {
  52. try {
  53. String scheme = null;
  54. String authority = null;
  55. String path = null;
  56. String fragment = null;
  57. return new URI(scheme,authority,path,fragment);
  58. }
  59. catch (URISyntaxException SyntaxError) {
  60. throw new IllegalStateException("unexpected",SyntaxError);
  61. }
  62. }
  63. }

输出

  1. URI.resolve(URI)
  2. EXPECTED: http://example.com/something/more/long?query=http://local:282/rand&action=aaaa
  3. but WAS: http://example.com/something/more/?query=http://local:282/rand&action=aaaa
  4. UriBuilder.replaceQuery(String)
  5. MATCHES: http://example.com/something/more/long?query=http://local:282/rand&action=aaaa
  6. UriBuilder.uri(URI)
  7. MATCHES: http://example.com/something/more/long?query=http://local:282/rand&action=aaaa

猜你在找的Java相关文章