Posso usare virgole in un URL?

Di solito uso la riscrittura degli URL per passare gli ID dei contenuti al mio sito Web, quindi questo

Foo.1.aspx 

riscrive a

  Foo.aspx?id=1 

Per un’applicazione specifica ho bisogno di passare più ID a una singola pagina, quindi ho riscritto le cose per accettarlo:

  Foo.1,2,3,4,5.aspx 

Funziona bene in Cassini (il web server ad hoc incorporato per Visual Studio) ma mi dà “Internet Explorer non può visualizzare la pagina web” quando lo provo su un server live con IIS. Si tratta di una limitazione di IIS? Devo usare solo trattini o caratteri di sottolineatura invece di virgole?

Ricordo che l’Url Routing di default controlla prima per vedere se il file esiste, e le virgole non sono legali nei nomi dei file, il che è il motivo per cui stai ricevendo errori. IIS potrebbe avere un codice legacy che abortisce la richiesta prima che possa arrivare ad asp.net per l’elaborazione.

Il post sul blog di Scott Hanselman parla un po ‘di questo e potrebbe essere rilevante per te.


Come commento generale: la riscrittura degli URL viene in genere utilizzata per rendere un URL facile da ricordare.

~/page.aspx?id=1,2,3,4 non è né peggiore né migliore di ~/page/1-2-3-4.aspx : entrambi sono difficili da usare, quindi perché passare allo sforzo extra? Evita di creare nuove forms di url solo perché è ansible. Utenti, help desk e altri sviluppatori saranno semplicemente confusi.

La riscrittura degli URL è meglio utilizzata per trasformare

 ~/products/view.aspx?id=1 ~/products/category.aspx?type=beverage 

in

 ~/products/view/1 ~/products/category/beverage 

Le virgole sono consentite nella parte del nome file di un URL, ma sono caratteri riservati nel dominio *, per quanto ne so.

Quale versione di IE stai usando? Ho trovato lo strano rapporto di IE5.5 troncando gli URL su una virgola ( link qui , ma ho testato URL con virgole in IE7 e sembra essere OK, quindi se c’è stato un bug di IE, non sembra esserci ancora – potrebbe essere un problema di IIS?

Mi chiedo se l’errore di pagina sia dovuto a un errore di regola con mod_rewrite – puoi pubblicare la regola che corrisponde a più ID e trasmetterli a Foo.aspx ? C’è qualche possibilità che Foo.N,N corrispondendo solo a Foo.N,N e fallendo con più virgole?


* Dall’URC RFC :

2.2. Personaggi riservati

Molti URI includono componenti costituiti da o delimitati da, alcuni caratteri speciali. Questi caratteri sono chiamati “riservati”, poiché il loro uso all’interno del componente URI è limitato al loro scopo riservato. Se i dati di un componente URI sono in conflitto con lo scopo riservato, i dati in conflitto devono essere preceduti da escape prima di formare l’URI.

  reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," 

La class di syntax “riservata” sopra si riferisce a quei caratteri che sono consentiti all’interno di un URI, ma che potrebbero non essere consentiti all’interno di un particolare componente della syntax URI generica

Prova a utilizzare %2c nell’URL per sostituire le virgole.

La virgola è consentita nel percorso, stringa di query e frammento in base alle specifiche. Non mi sorprenderebbe se IE non fosse conforms alle specifiche. Prova l’ quadro come suggerisce Claudiu, ma non so perché sarebbe necessario.

Oltre alla risposta di ConroyP, sotto c’è un’altra citazione alla RFC. Rileva un numero di caratteri non sicuri, ma non menziona la virgola (suggerendo che la virgola è sicura):

I personaggi possono essere insicuri per una serie di motivi. Il carattere dello spazio non è sicuro perché gli spazi significativi possono scomparire e spazi insignificanti possono essere introdotti quando gli URL sono trascritti o composti o sottoposti al trattamento di programmi di elaborazione testi. I caratteri “<" e ">” non sono sicuri perché vengono utilizzati come delimitatori attorno agli URL in testo libero; il segno di virgoletta (“” “) viene utilizzato per delimitare gli URL in alcuni sistemi.Il carattere” # “non è sicuro e deve essere sempre codificato perché viene utilizzato nel World Wide Web e in altri sistemi per delimitare un URL da un frammento / ancora identificatore che potrebbe seguirlo. Il carattere “%” non è sicuro perché viene utilizzato per codifiche di altri caratteri. Altri caratteri non sono sicuri poiché i gateway e altri agenti di trasporto sono talvolta in grado di modificare tali caratteri. Questi caratteri sono “{“, “} “,” | “,” \ “,” ^ “,” ~ “,” [“,”] “e” `”.

Tutti i caratteri non sicuri devono sempre essere codificati all’interno di un URL. Ad esempio, il carattere “#” deve essere codificato all’interno degli URL anche in sistemi che normalmente non si occupano di frammenti o identificatori di ancoraggio, in modo che se l’URL viene copiato in un altro sistema che li utilizza, non sarà necessario modificare il Codifica dell’URL.

Il modo giusto per accettare più ID è come questo:

 Foo.aspx?id=1;id=2;id=3;id=4;id=5 

Nota che è proprio quello che è l’objective. Quando riscrivi gli URL, puoi impostare le tue regole in una certa misura per quello che vuoi che sia la fonte.

Ho dovuto imparare questo anche su StackOverflow. Vedi questa domanda:
Suddividi gli intagli dalla stringa

Risposta

Il problema erano le virgole. Sto indovinando che IIS stava avendo un problema con esso (non IE) poiché IE era in grado di visualizzarlo bene su localhost.

In ogni caso ho appena cambiato il formato dell’URL e funziona perfettamente:

 Foo.1-2-3-4-5.aspx 

Se avessi messo in atto un controller frontale, potevi fare qualcosa del genere;

 index.aspx?c=Foo/1/2/3/4 

Il Front Controller avrebbe raccolto il nome del metodo e i parametri da passare ad esso. Questa è una tecnica abbastanza comune al giorno d’oggi.