Newsgroup: it.comp.sicurezza.varie
Titolo: Dubbio...

Sicuramente è cosa già nota e sono io che, causa sonno arretrato, non 
sono riuscito a trovare documentazione in merito.
In caso, mi scuso in anticipo per il falso allarme.
Lanciando l'url seguente con IE 5.5 sp2 e tutte le fix si viene 
rediretti sulla pagina di google.
http://www.playboy.com@%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d
Un occhio attento (e non condizionato dall'url che ho piazzato prima 
della @ e dal sonno arretrato) avrà notato che si tratta di un 
"trucco" semplicissimo.
L'URL di destinazione è "nascosta" inserendo i corrispondenti codici 
ASCII dopo la chiocciolina. In questo modo tutto quello che precede 
la chiocciolina è interpretato come "credenziali di login" per l'url 
seguente e bellamente ignorato (perlomeno da IE).
Un occhio disattento però potrebbe scambiare l'url qui sotto per ben 
altro e lasciarsi ingannare e redirigere su un sito parecchio diverso 
da quello che si aspettava (aggiungere un pò di fuffa "pseudo get 
request" dopo 
playboy.com
 avrebbe sicuramente reso l'url ancora più 
ingannevole e magari convinto l'utente che l'eseguibile che gli si 
chiede di scaricare proviene da un sito affidabile...).
Il problema è che IE 5.5 non "decodifica" in alcun modo l'url e nella 
barra degli indirizzi viene visualizzata l'URL "camuffata".
Chiunque abbia un minimo di familiarità con l'HTML e i frame può 
trarre le debite conclusioni sui possibili utilizzi di questa 
"feature".
Quelli di opera ci hanno pensato e l'url appare (decodificata in 
testo) solo dopo un messaggio di avvertimento che segnala che si sta 
accedendo a un sito (
www.google.com
) con un nome utente 
(
www.playboy.com
 e fuffa).
Mi sono perso qualche patch o è un comportamento normale?
In caso, IE 6 continua a comportarsi allo stesso modo?
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 In caso, IE 6 continua a comportarsi allo stesso modo?
Arogomento interessante il tuo, sto provando varie cosette e sai
cosa sto pensando? Che per ora il piů immune da tali cose per ora
é Mozilla....ma vedremo...
-- 
PGP FP: B61A F1FA 9B99 A3BD 5D2B 6D99 8D3A 5C92 3525 3509

 In caso, IE 6 continua a comportarsi allo stesso modo?
A me IE6 restituisce l'url decodificata, cosě anche opera 6 sotto windows.

 In caso, IE 6 continua a comportarsi allo stesso modo?
Feature interessante.
IE 6.0.2600.0000 Versione inglese non effettua alcuna decodifica e non da
alcun messaggio di alert.
Mi piacerebbe approfondire la cosa, per caso sapresti dirmi dove posso
trovare delle documentazioni in merito.
AMS67
--
Quidquid latine dictum sit, altum viditur. (Whatever is said in Latin sounds
profound.)

 http://www.playboy.com@%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d
Opera 5 avvisa della cosa, da' un security warning.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 Anche Opera 6 avvisa.
HO Opera 5.2 ITA ma lo uso poco in quanto crasha....spesso :)


 
Netscape è immune, squid mi diche che l'url non è valida
-- 
Roberto Tagliaferri<-> r.tagliaferri@(forse)
tosnet.it
	Il giovane marito si ammira nudo allo specchio...
	"Vedi cara, con qualche centimetro in più sarei un re"
	e la moglie "e con qualche centimetro di meno saresti una regina!"

 
A me piacerebbe trovare della documentazione che dice che questa è una 
"known issue" e non c'è da preoccuparsi...
Proverò a scrivere alla ms, a questo punto sono abbastanza sicuro che non 
si tratta di un problema solo mio.


 Confermo: IE 5.5 patchato non da' alcun avviso.
Effettivamente non ci avevo pensato.
In questo modo è abbastanza difficile capire l'inghippo, soprattutto 
con URL un po' complicate da & e ?.


 wrote in
news:p1v63a.00l.ln@pinguin: 

A me IE6 (ver 6.0.2600 inglese e con tutte le fix) non decodifica 
l'URL.
Hai una versione diversa?


 trovare delle documentazioni in merito.
Prova a dare un occhio a 
http://www.pc-help.org/obscure.htm
Fabio

 Netscape è immune, squid mi diche che l'url non è valida
Quindi IE dietro a un proxy linux dovrebbe essere al sicuro.
In effetti prima della @ dovrebbero esserci username e password (non sò 
se è prevista la possibilità di omettere la password, appena posso 
cerco tra le RFC).
La password però potrebbe essere "pasticciata" in ASCII (come whiplash 
ha fatto con la @) e l'url a quel punto sarebbe completamente valida.


testo) solo dopo un messaggio di avvertimento che segnala che si sta 
Netscape® Communicator 4.75 
430 Not found
Unable to resolve name:
www.playboy.com@%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d
...pero':
http://%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d/
430 Not found
Unable to resolve name:
www.%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%
6d.com
...Mi sa che questa versione ha _altri_ problemi.... :?
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Cannot delete files, disk full. Try to delete some file.

 
Che Mozilla hai?? Il mio ( 0.8)  "beve" che è un piacere...e anche Netscape
4.77..
 L' unico che mi risolve parzialmente gli indirizzi è Konqueror...
stinger

 cerco tra le RFC).
Siete sicuri? La decodifica e' a carico di IE e la richiesta al
proxy contiene l'url gia decodificata. Giusto per essere sicuro
ho appena fatto una prova.
Fabio

 
Ti ricordi se c'era anche una patch?


 stinger
Rettifica...., volevo dire che una volta clickato sulla url incriminata,
tutti mi danno nella barra degli indirizzi l'indirizzo esatto....., ma
solo Konqueror mi decodifica parte dell'indirizzo ( non sempre..) 
passandoci sopra senza bisogno di clickare.....
stinger

 wrote in
news:dKO58.6254$
ue2.1...@twister1.libero.it
: 

La decodifica, perlomeno quella del nome del server ed eventuali 
username e password, dovrebbe essere a carico del browser (altrimenti 
non potrebbe gestire la cosa senza passare da un proxy, a meno che il 
DNS non accetti nomi "codificati", cosa di cui dubito).
Non capisco perchè non si siano presi la briga di riportare la 
versione decodificata nella address bar (anche perchè se ci copi un 
indirizzo http con caratteri non validi provvede a fare la codifica 
con %<codice ASCII>).
E' stato segnalato che squid (che io ho indicato un po' troppo 
genericamente come "proxy linux") respinge come non valida l'URL 
richiesta (versione decodificata) e ho ipotizzato che sia perchè non 
è possibile specificare uno username senza la relativa password o 
almeno il separatore (limitazione che però potrebbe essere aggirata 
"pastrocchiando" il ':' e la password allo stesso modo).
Il problema è che IE lascia che vengano passati come codici ASCII 
anche caratteri perfettamente validi e stampabili e non si preoccupa 
di avvisare in alcun modo l'utente di questo, cosa che invece fanno 
opera (con message box e decodifica dell'URL) e konqueror.



Il mio IE ( ver 6.0.2600 italiano con patch Q313675) decodifica
perfettamente...
stinger

 opera (con message box e decodifica dell'URL) e konqueror.
Ho provato con opera e non mi sembra che avverta per l'url codificato
in hex. Fa solo la decodifica (versione 6.0).
Fabio

 ho appena fatto una prova.
concordo
-- 
PGP FP: B61A F1FA 9B99 A3BD 5D2B 6D99 8D3A 5C92 3525 3509
www.x-planet.org

 Netscape è immune, squid mi diche che l'url non è valida
Netscape non lo uso...a parte che il motore di base è lo stesso che
di Mozilla...
-- 
PGP FP: B61A F1FA 9B99 A3BD 5D2B 6D99 8D3A 5C92 3525 3509
www.x-planet.org

  L' unico che mi risolve parzialmente gli indirizzi è Konqueror...
0.90 ecc
-- 
PGP FP: B61A F1FA 9B99 A3BD 5D2B 6D99 8D3A 5C92 3525 3509
www.x-planet.org

 Prova a dare un occhio a 
http://www.pc-help.org/obscure.htm
Grazie!
AMS67
--
Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music.

opera (con message box e decodifica dell'URL) e konqueror.
In effetti la RFC non lo prevede... (RFC 1945, pagg. 13-14)


 fatto una prova.
Strano: a me pare che sia il mio squid, locale, a cercare di
decodificare.
Se abilito il proxy, infatti, ho
While trying to retrieve the URL: 
http://www.playboy.com
%40%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d/
The following error was encountered:
    * Invalid URL
Disabilitando il proxy, e' Netscape 6.2 a darmi l'alert.
(versione con %40 al posto di @)

 hex. Fa solo la decodifica (versione 6.0).
A me, invece da' un'alert proprio sulla codifica.
Uhm...i browser entita' stocastiche? ;)

Ti ricordi se c'era anche una patch?
No, e non ricordo neppure il titolo del thread. 


 Uhm...i browser entita' stocastiche? ;)
A me da un alert ma per la presenza di dati di autenticazione
e non per la codifica. Se tolgo il campo <userinfo> ma lascio
l'url codificato in hex non mi dice niente.
Fabio

 
Effettivamente al paragrafo 2.2 dice:
On the other hand, characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.
e, considerando che il carattere @ è un carattere riservato nel caso di 
url HTTP, non dovrebbe essere possibile sostituirlo con %40 o altre 
codifiche.
Al paragrafo 3.1 (descrizione comune per tutti i tipi di URL) dice che 
la password è opzionale (questo smentisce il mio dubbio):
   Some or all of the parts "<user>:<password>@", ":<password>",
   ":<port>", and "/<url-path>" may be excluded.  
Più avanti parla della codifica di eventuali caratteri riservati 
presenti all'interno di username e password
   The user name (and password), if present, are followed by a
   commercial at-sign "@". Within the user and password field, any ":",
   "@", or "/" must be encoded.
Quindi l'URL postata da whiplash (con %40 al posto di @) non deve 
essere considerata com  valida (o perlomeno la prima parte dell'url non 
dovrebbe essere interpretata come username da passare al sito 
codificato dopo il %40).
Al punto 3.3 (come dici tu) esclude completamente la possibilità di 
passare username e password direttamente tramite un URL HTTP:
   An HTTP URL takes the form:
      http://<host>:<port>/<path>?<searchpart>
   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  
E questo spiega perchè questi campi vengono convertiti in header della 
request HTTP nel momento in cui vengono passati al browser o al sito.
A questo punto sembra che IE non rispetti perlomeno il secondo punto 
della RFC riportato (codifica dei caratteri riservati all'interno dello 
username) nella conversione di quanto specificato nella barra degli 
indirizzi (o tramite shortcut e quindi linea di comando) 
nell'equivalente header HTTP.
Comunque, al di là della validita "formale" delle URL in discussione, 
rimane il fatto che (perlomeno in alcuni casi), l'utente potrebbe 
essere indirizzato su un sito diverso da quello che vede in chiaro 
nell'url.
<ottimista a tutti i costi>
Fortunatamente, invece, il "giochino" sembra non aver effetti sulla 
"security zone" cui viene assegnato il sito. Anche inserendo un sito 
"trusted" nella prima parte dell'URL viene considerato correttamente il 
sito "codificato" 
</ottimista  a tutti i costi>


 (versione con %40 al posto di @)
Mah, la parte network location dovrebbe essere passata al DNS,
per risolvere l'IP, o al proxy per delegare la GET.
Nel caso in cui dovesse andare al DNS direi che dovrebbe venir
decodificata prima, perche' il DNS non la accetterebbe 'as is'.
Mi viene da pensare che la procedura sia uguale anche nel caso
di richieste al proxy. Se non altro per semplicita'.
Comunque IE 5.0, 6.0 e Opera 6.0 decodificano prima di inviare
la richiesta al proxy.
0x0000   4500 01bc b630 4000 7f06 7857 c0a8 010a        E....0@...xW....
0x0010   0a00 0002 1033 0c38 9405 4d48 a336 5eb2        .....3.8..MH.6^.
0x0020   5018 4470 18c1 0000 4745 5420 6874 7470        P.Dp....GET.http
0x0030   3a2f 2f77 7777 2e67 6f6f 676c 652e 636f        ://
www.google.co
0x0040   6d2f 2048 5454 502f 312e 300d 0a41 6363        m/.HTTP/1.0..Acc
0x0050   6570 743a 2069 6d61 6765 2f67 6966 2c20        ept:.image/gif,.
0x0060   696d 6167 652f 782d 7862 6974 6d61 702c        image/x-xbitmap,
0x0070   2069 6d61 6765 2f6a 7065 672c 2069 6d61        .image/jpeg,.ima
0x0080   6765 2f70 6a70 6567 2c20 6170 706c 6963        ge/pjpeg,.applic
0x0090   6174 696f 6e2f 766e 642e 6d73 2d70 6f77        ation/vnd.ms-pow
0x00a0   6572 706f 696e 742c 2061 7070 6c69 6361        erpoint,.applica
0x00b0   7469 6f6e 2f76 6e64 2e6d 732d 6578 6365        tion/vnd.ms-exce
0x00c0   6c2c 2061 7070 6c69 6361 7469 6f6e 2f6d        l,.application/m
0x00d0   7377 6f72 642c 202a 2f2a 0d0a 4163 6365        sword,.*/*..Acce
0x00e0   7074 2d4c 616e 6775 6167 653a 2069 740d        pt-Language:.it.
0x00f0   0a43 6f6f 6b69 653a 2050 5245 463d 4944        .Cookie:.PREF=ID
0x0100   3d32 6364 3562 3265 6232 6463 3335 6164        =2cd5b2eb2dc35ad
0x0110   623a 544d 3d31 3030 3533 3131 3235 393a        b:TM=1005311259:
0x0120   4c4d 3d31 3030 3533 3131 3235 393a 533d        LM=1005311259:S=
0x0130   4e68 3041 685a 3547 3173 4d0d 0a55 7365        Nh0AhZ5G1sM..Use
0x0140   722d 4167 656e 743a 204d 6f7a 696c 6c61        r-Agent:.Mozilla
0x0150   2f34 2e30 2028 636f 6d70 6174 6962 6c65        /4.0.(compatible
0x0160   3b20 4d53 4945 2036 2e30 3b20 5769 6e64        ;.MSIE.6.0;.Wind
0x0170   6f77 7320 4e54 2035 2e30 3b20 5133 3132        ows.NT.5.0;.Q312
0x0180   3436 3129 0d0a 486f 7374 3a20 7777 772e        461)..Host:.www.
0x0190   676f 6f67 6c65 2e63 6f6d 0d0a 5072 6f78        google.com..Prox
0x01a0   792d 436f 6e6e 6563 7469 6f6e 3a20 4b65        y-Connection:.Ke
0x01b0   6570 2d41 6c69 7665 0d0a 0d0a                  ep-Alive....
Ho postato tutta la richiesta per mostrare, tra l'altro, che manca il
campo authorization.
Fabio

 In caso, IE 6 continua a comportarsi allo stesso modo?
Anche in presenza di browser che decodificano l'URL, usando l'indirizzo IP 
(magari in forma "no dotted") il trucco continua a funzionare. Inoltre usando 
i due punti per specificare una password alcuni proxy non protestano (tipo 
wwwoffle).
Esempio:
http://www.microsoft.com
&news=6593&article:=1209@3333866552
-- 
Lorenzo

A questo punto sembra che IE non rispetti perlomeno il secondo punto 
Ero arrivato alla stessa conclusione.
In effetti nella RFC sembra essere suggerita la seguente procedura di
parsing e decodifica:
1) smembrare l'indirizzo digitato nelle sue singole parti
2) decodifica
IMHO quei genialoidi di Redmon hanno fatto l'esatto contrario
(peraltro facendo confusione e decodificando in piu' punti, per cui
esistono problemi di doppia codifica, eccetera).
Partiamo dalla URL originaria senza la chiocciola:
http://www.playboy.com
%40%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d
Smembrando la url si ottiene
Proto: http:
Host: 
www.playboy.com
%40%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d
Resource: /
Per cui, correttamente, si dovrebbe riportare l'errore 410.
Invece i geniacci di IE:
decodificano:
http://www.pla...@www.google.com
smembrano
Proto: http:
Username: 
www.playboy.com
Host: 
www.google.com
Resource: /
E, chiaramente, sorge il problema.
Faccio notare che la RFC non prevede ne' una doppia decodifica
(%32%35%33%34%33%30 non deve diventare %40 ne, tantomeno, @) ne che i
delimitatore delle parti (://, @, :, /) possano essere codificati.
In questo senso, la risposta corretta e' quella riportata dal "mio"
netscape! :)



http://www.microsoft.com
&news=6593&article:=1209@3333866552
La cosa mi pare corretta. 
Si suppone infatti (vedi mio post precedente, di un minuto fa) che il
parsing (tokeing?) avvenga da sinistra a destra.
dopo il protocollo e relativo separatore (://) dovrebbe esservi lo
username, opzionale, la pasword, opzionale, separati dalla chiocciola,
quindi l'indirizzo dell'host:
proto: http
Username: 
www.microsoft.com
&news=6593&article
Password: =1209
Host: 3333866552
Resource: /


 risolvere l'IP, o al proxy per delegare la GET.
La mia idea e' che, nel mio caso, il browser passi al
proxy la stringa "as it is"
Quel che ho al momento e' quanto segue:
15:23:24.879556 naxalite.38756 > naxalite.webcache: S
782077582:782077582(0)
15:23:24.879624 naxalite.webcache > naxalite.38756: S 787519430:787519430(0)
ack 782077583
15:23:24.880616 naxalite.32770 > naxalite.domain:  72+ 
A? 
www.debian.org
. (32) (DF)
e che quindi, in effetti, entra in gioco prima squid e poi il
domain.
Ora greppo le richieste al proxy per vedere cosa effetivamente
arriva a squid, in termini di stringa.

 inviare la richiesta al proxy.
Netscape, come supponevo, no.
(richiesta al proxy)
0000  00 00 03 04 00 00 00 00  00 00 00 00 00 00 08 00   ........ ........
0010  45 00 02 5c ea 6e 40 00  40 06 50 2b 7f 00 00 01   E..\ên@. @.P+....
0020  7f 00 00 01 98 ca 1f 90  02 e0 9b 2d 02 98 be f2   .....Ê.. .à.-..¾ò
0030  80 18 7f ff 59 6f 00 00  01 01 08 0a 00 26 71 40   ...ÿYo.. .....&q@
0040  00 26 71 40 47 45 54 20  68 74 74 70 3a 2f 2f 77   .&q@GET  
http://w
0050  77 77 2e 70 6c 61 79 62  6f 79 2e 63 6f 6d 40 25   ww.playb oy.com@%
0060  37 37 25 37 37 25 37 37  25 32 65 25 36 37 25 36   77%77%77 %2e%67%6
0070  66 25 36 66 25 36 37 25  36 63 25 36 35 25 32 65   f%6f%67% 6c%65%2e
0080  25 36 33 25 36 66 25 36  64 2f 20 48 54 54 50 2f   %63%6f%6 d/ HTTP/
0090  31 2e 31 0d 0a 48 6f 73  74 3a 20 25 37 37 25 37   1.1..Hos t: %77%7
00a0  37 25 37 37 25 32 65 25  36 37 25 36 66 25 36 66   7%77%2e% 67%6f%6f
00b0  25 36 37 25 36 63 25 36  35 25 32 65 25 36 33 25   %67%6c%6 5%2e%63%
00c0  36 66 25 36 64 0d 0a 55  73 65 72 2d 41 67 65 6e   6f%6d..U ser-Agen
00d0  74 3a 20 4d 6f 7a 69 6c  6c 61 2f 35 2e 30 20 28   t: Mozil la/5.0 (
00e0  58 31 31 3b 20 55 3b 20  4c 69 6e 75 78 20 69 36   X11; U;  Linux i6
00f0  38 36 3b 20 65 6e 2d 55  53 3b 20 72 76 3a 30 2e   86; en-U S; rv:0.
0100  39 2e 34 29 20 47 65 63  6b 6f 2f 32 30 30 31 31   9.4) Gec ko/20011
0110  31 32 36 20 4e 65 74 73  63 61 70 65 36 2f 36 2e   126 Nets cape6/6.
0120  32 2e 31 0d 0a 41 63 63  65 70 74 3a 20 74 65 78   2.1..Acc ept: tex
0130  74 2f 78 6d 6c 2c 20 61  70 70 6c 69 63 61 74 69   t/xml, a pplicati
0140  6f 6e 2f 78 6d 6c 2c 20  61 70 70 6c 69 63 61 74   on/xml,  applicat
0150  69 6f 6e 2f 78 68 74 6d  6c 2b 78 6d 6c 2c 20 74   ion/xhtm l+xml, t
0160  65 78 74 2f 68 74 6d 6c  3b 71 3d 30 2e 39 2c 20   ext/html ;q=0.9, 
0170  69 6d 61 67 65 2f 70 6e  67 2c 20 69 6d 61 67 65   image/pn g, image
0180  2f 6a 70 65 67 2c 20 69  6d 61 67 65 2f 67 69 66   /jpeg, i mage/gif
0190  3b 71 3d 30 2e 32 2c 20  74 65 78 74 2f 70 6c 61   ;q=0.2,  text/pla
01a0  69 6e 3b 71 3d 30 2e 38  2c 20 74 65 78 74 2f 63   in;q=0.8 , text/c
01b0  73 73 2c 20 2a 2f 2a 3b  71 3d 30 2e 31 0d 0a 41   ss, */*; q=0.1..A
01c0  63 63 65 70 74 2d 4c 61  6e 67 75 61 67 65 3a 20   ccept-La nguage: 
01d0  65 6e 2d 75 73 0d 0a 41  63 63 65 70 74 2d 45 6e   en-us..A ccept-En
01e0  63 6f 64 69 6e 67 3a 20  67 7a 69 70 2c 20 64 65   coding:  gzip, de
01f0  66 6c 61 74 65 2c 20 63  6f 6d 70 72 65 73 73 3b   flate, c ompress;
0200  71 3d 30 2e 39 0d 0a 41  63 63 65 70 74 2d 43 68   q=0.9..A ccept-Ch
0210  61 72 73 65 74 3a 20 49  53 4f 2d 38 38 35 39 2d   arset: I SO-8859-
0220  31 2c 20 75 74 66 2d 38  3b 71 3d 30 2e 36 36 2c   1, utf-8 ;q=0.66,
0230  20 2a 3b 71 3d 30 2e 36  36 0d 0a 4b 65 65 70 2d    *;q=0.6 6..Keep-
0240  41 6c 69 76 65 3a 20 33  30 30 0d 0a 50 72 6f 78   Alive: 3 00..Prox
0250  79 2d 43 6f 6e 6e 65 63  74 69 6f 6e 3a 20 6b 65   y-Connec tion: ke
0260  65 70 2d 61 6c 69 76 65  0d 0a 0d 0a               ep-alive ....


Nono, e' normale: se usi una sola parola NS aggiunge www in testa e .com
alla fine, per aiutare gli utenti americani.
Ciaotutti,
*


Idem.............................
*You see Lux disconcerted in front what he said*

Raga se clicco su
http://www.playboy.com
%40%77%77%77%2e%67%6f%6f%67%6c%65%2e%63%6f%6d/
L'url mi viene decodificata
mentre se clicco
http://www.provamiosito.com@%77%77%77%2E%63%6F%6E%64%6F%6D%69%6E%69%6F%77%65
%62%2E%63%6F%6D
l'ulr non mi viene decodificata
Puo' dipendere dalla lunghezza ?
Ie 6.0

 La cosa mi pare corretta.
Infatti lo č, anche per quanto ne so io...:) Mi riferivo al fatto che alcuni 
proxy (tra cui WWWoffle) danno errore se non viene specificata la password 
(che negli RFC se non sbaglio č opzionale).
Sai mica perchč se metto uno slash nell'username il trucchetto non funziona 
piů ?
Ad esempio:
http://www.microsoft.com/&news=6593&article:=1209@3333866552
Va direttamente al sito MS...
-- 
Lorenzo

 
Credo sia dovuto al fatto che lo '/' è un carattere riservato e, come 
tale, dovrebbe essere "codificato" con %<codice ASCII> se è parte di 
username o password (paragrafo 2.2. della RFC 1738), anche se la 
stessa RFC esclude URL http con username e password e quindi 
l'interpretazione di quella parte dell'URL (e relativa traduzione in 
header HTTP) è lasciata al browser.
In teoria lo stesso "trattamento" dovrebbe essere riservato pure alla 
chiocciolina, ma IE (perlomeno fino alla 5.5) sembra accettare anche 
il %40.


 Va direttamente al sito MS...
Credo che dipenda dal fatto che il browser consideri tutto ciň che sta dopo
lo / come una sezione del sito che sta prima dello /.
Per esempio:
http://guide.supereva.it
porta alla pagina di tutte le guide di supereva, mentre
http://guide.supereva.it/bari/
porta ad una particolare guida di supereva, quella di Bari.
Cmq non sono esperta, potrei anche sbagliarmi.
-g-

alla fine, per aiutare gli utenti americani.
Ok, ma perche' non lo decodifica? hai provato con
www.%67%6f%6f%67%6c%
65.com
?


Va direttamente al sito MS...
Ovvio: e' il separatore tra i "token"...  la grammatica prevede
Protocollo :// [username[:passwor]@] host [:porta] [/indirizzo
assoluto]


 il %40.
anche con IE 6
2k1

 netscape! :)
Si, ma a rigor di termini @ non e' un carattere riservato negli url http :)
La cosa trova forse conferma anche oltre, quando la rfc dice che i /, @, ?,
ecc. _possono_ essere caratteri riservati all'interno di uno s chema, e non
che lo sono indipendentemente dal contesto.
Fabio

 --
Mi sa che non lofa proprio mai...Io con NS non ho maiavuto problemidi
decodifica ad apparatoriproduttivo dilevriero, neinomi diserver...
Ciaotutti,
*

che lo sono indipendentemente dal contesto.
Aspetta... Non ho la RFC sotto mano, ora... ma a rigore, _dovrebbe_
essere "riservato" in quanto un "delimitatore di campo" della sintassi
della URL. Da quel che ho capito/dedotto e che ricordo, la decodifica
andrebbe applicata _dopo_ la suddivisione dei campi, non prima.
In tal caso, non vi sarebbero ambiguita'...


 In tal caso, non vi sarebbero ambiguita'...
Penso che la cosa si possa prestare a diverse interpretazioni.
A pagina 3 della rfc1738 si legge:
<< Many URL schemes reserve certain characters for a special meaning:
   their appearance in the scheme-specific part of the URL has a
   designated semantics. If the character corresponding to an octet is
   reserved in a scheme, the octet must be encoded.  The characters ";",
   "/", "?", ":", "@", "=" and "&" are the characters which may be
   reserved for special meaning within a scheme. No other characters may
   be reserved within a scheme. >>
Il primo periodo lascia intendere che i caratteri possono essere riservati
o meno a seconda dello schema (http, ftp, ecc.) a cui appartiene l'url.
Il secondo periodo rafforza questa interpretazione dicendo "se un carattere
e' riservato in uno schema...". Il terzo non e' da meno in quanto dice che
i caratteri citati "potrebbero" essere riservati in uno schema.
Andando al paragrafo 3.3 (schema http) non si trovano riferimenti al campo
di autenticazione (come avevamo gia' visto la settimana scorsa) e l'url
tipo viene presentato come:
http://<host>:<port>/<path>?<searchpart>
Una possibile interpretazione di tutto cio' potrebbe essere:
- i caratteri riservati sono tali solo all'interno di uno schema specifico
- lo schema specifico http non prevede la chiocciola
=> la chiocciola non e' un carattere riservato in http
Fabio

=> la chiocciola non e' un carattere riservato in http
Ok, tuttavia al paragrafo 2.2:
<<   Usually a URL has the same interpretation when an octet is
   represented by a character and when it encoded. However, this is
not
   true for reserved characters: encoding a character reserved for a
   particular scheme may change the semantics of a URL.
   Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL. >>
Inoltre l'inizio del 3.1 dovrebbe tagliare la testa al toro:
<<   While the syntax for the rest of the URL may vary depending on
the
   particular scheme selected, URL schemes that involve the direct use
   of an IP-based protocol to a specified host on the Internet use a
   common syntax for the scheme-specific data:
        //<user>:<password>@<host>:<port>/<url-path>
  ...>>
Insomma, checche' ne dica il par. 3.3 specifico di http, la sintassi
comune ha prevalenza. quindi secondo questa interpretazione la "@"
dovrebbe essere riservata e user:password una sintassi lecita.


 dovrebbe essere riservata e user:password una sintassi lecita.
E, si!  E' per la presenza dei paragrafi da te citati che dico che
l'interpretazione puo' essere ambigua.
Bisogna vedere se effetivamente la parte generale ha prevalenza su
quella specifica o meno per quelle parti di url che non dovrebbero
esserci ma che, invece, sono tollerate dal browser. Evidentemente
alla microsoft hanno scelto l'approccio "e' una parte che non deve
esserci e quindi la interpreto come voglio". Alla fine dei conti e'
un atteggiamento non meno arbitrario di quello tenuto da opera che
prende le credenziali fornite e le ficca nel campo Authorization.
Se non altro, pero', opera avverte della presenza dell'anomalia ed
e' questo che ha importanza per l'utente finale.
Fabio

esserci e quindi la interpreto come voglio". Alla fine dei conti e'
...come al solito...
a me par tanto che alla M$ abbiano cappellato il concetto di fondo, e
adesso cerchino di metterci una qualche pezza senza riscriverlo...


 adesso cerchino di metterci una qualche pezza senza riscriverlo...
No, no... non e' possibile! Zio guglielmo non e' fatto cosi'.
E poi fa anche beneficenza a favore dei popoli del terzo mondo.
... sei un ingrato :)
Fab