¿por qué colon ":" en Uri pasó a Uri.MakeRelativeUri causar una excepción?

Question

La siguiente línea de código ofrece una excepción. ¿Es esto un error en el marco? Si no, ¿qué enfoque podría tomar en su lugar?

Parece ser el ":" (dos puntos) que causa en el tema, sin embargo, me veo como un URI de trabajo en los sitios web de producción ok (es decir, parece que hay un URI válido en el mundo real)

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xx:yy")); 
// gives => System.UriFormatException: A relative URI cannot be created because the 
// 'uriString' parameter represents an absolute URI 

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xxyy")); 
// this works - removed the colon between the xx and yy 

PS. Específicamente puedo preguntar dado que es el caso, qué clase/método .NET podría usar (teniendo en cuenta que estoy analizando una página HTML de la web) para tomar (a) el URI de la página y (b) la cadena relativa de un HTML Argumento HREF [ej. habría sido "/ xx: yy" en este caso] y devolver el URI válido que podría utilizarse para abordar ese recurso?

En otras palabras, ¿cómo imito el comportamiento de un navegador que traduce el HREF y el URI de página para producir el URI que utiliza para ir a ese recurso cuando hace clic en él.

Answer 1

Lo considero un error.

RFC1738 dice que : (entre otros caracteres) puede se reserva para un significado especial dentro de un esquema. Sin embargo, el esquema de http no se reserva en la parte de la ruta

Within the <path> and <searchpart> components, "/", ";", "?" are reserved. 

(No :.)

hsegment  = *[ uchar | ";" | ":" | "@" | "&" | "=" ] 

Así, http://test.com/xx:yy es un URI válido. El más reciente RFC3968 está de acuerdo:

pchar   = unreserved/pct-encoded/sub-delims/":"/"@" 

Sin embargo, por supuesto, relativizado contra http://test.com/asdf, la resultante xx:yy habría un URI absoluto y no un URI relativo válida:

path-noscheme = segment-nz-nc *("/" segment) 
segment-nz-nc = 1*(unreserved/pct-encoded/sub-delims/"@") 
       ; non-zero-length segment without any colon ":" 

Así MakeRelativeUri es una especie de derecho de informar hay un problema, pero en realidad es si lo está arreglando automáticamente codificando el : que es válido en un URI absoluto a un %3A que es válido en el primer segmento de un URI relativo.

En general, trataré de evitar MakeRelativeUri a favor de los URI de raíz, que son más fáciles de extraer y no tienen este problema (/xx:yy está bien).

Answer 2

Los puntos juegan un papel especial en las URL: para denotar un puerto, por ejemplo, están 'reservados' (see here).

Las URL utilizan algunos caracteres para el uso especial en la definición de su sintaxis. Cuando estos personajes no se utilizan en su papel especial dentro de una URL, que necesitan a codificar

Así, el colon debe ser escapado.

Answer 3

Si se encuentran dos puntos, intenta analizar el valor que sigue a dos puntos como número de puerto y fallará si no proporciona un número de puerto válido. Consulte here para ver un ejemplo de un problema similar y MSDN link for UriFormatException details.