Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21167 > unrolled thread

htaccess strani

Back to article view | Back to it.comp.www.php

Contents

  htaccess strani Greg <greg@alicie.com> - 2016-09-26 11:43 +0200
    Re: htaccess strani fmigliori <fmigliori@gmail.com> - 2016-09-26 02:51 -0700
      Re: htaccess strani Greg <greg@alicie.com> - 2016-09-26 14:55 +0200
        Re: htaccess strani fmigliori <fmigliori@gmail.com> - 2016-09-26 10:24 -0700
          Re: htaccess strani Greg <greg@alicie.com> - 2016-09-26 21:16 +0200
            Re: htaccess strani "ciccio" <21669invalid@mynewsgate.net> - 2016-09-26 19:31 +0000
          Re: htaccess strani fmassei@gmail.com - 2016-09-26 14:04 -0700
    Re: htaccess strani fmassei@gmail.com - 2016-09-26 12:42 -0700
      Re: htaccess strani Greg <greg@alicie.com> - 2016-09-26 22:31 +0200
        Re: htaccess strani fmassei@gmail.com - 2016-09-26 13:48 -0700
          Re: htaccess strani Greg <greg@alicie.com> - 2016-09-26 23:48 +0200
            Re: htaccess strani fmassei@gmail.com - 2016-09-26 15:10 -0700
              Re: htaccess strani Greg <greg@alicie.com> - 2016-09-27 13:50 +0200
                Re: htaccess strani Alessandro Pellizzari <shuriken@amiran.it> - 2016-09-27 13:13 +0100
                Re: htaccess strani fmassei@gmail.com - 2016-09-27 10:38 -0700
                  Re: htaccess strani Greg <greg@alicie.com> - 2016-09-27 23:13 +0200
                    Re: htaccess strani fmassei@gmail.com - 2016-09-27 18:49 -0700
                      Re: htaccess strani Greg <greg@alicie.com> - 2016-09-28 10:23 +0200
                        Re: htaccess strani fmassei@gmail.com - 2016-09-28 10:45 -0700
                      Re: htaccess strani Greg <greg@alicie.com> - 2016-09-28 10:27 +0200

#21167 — htaccess strani

Sto trovando che molti siti e blog hanno un problema uguale al mio.
Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di parole viene visualizzata la pagina 
precedente ma con tutta la schifezza aggiunta dopo.
Ma si capisce meglio dall'esempio:
http://my.jetscreenshot.com/5512/20160926-2t9t-37kb.jpg

-- 
Greg

[toc] | [next] | [standalone]

#21168

Il giorno lunedì 26 settembre 2016 11:43:34 UTC+2, Greg ha scritto:
> Sto trovando che molti siti e blog hanno un problema uguale al mio.
> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di parole viene visualizzata la pagina 
> precedente ma con tutta la schifezza aggiunta dopo.
> Ma si capisce meglio dall'esempio:
> http://my.jetscreenshot.com/5512/20160926-2t9t-37kb.jpg
> 
> -- 
> Greg

Non è un problema, è la pagina 404 senza scritto 404.

[toc] | [prev] | [next] | [standalone]

#21173

Il 26/09/16 11:51:15 fmigliori ha scritto:
> Il giorno lunedì 26 settembre 2016 11:43:34 UTC+2, Greg ha scritto:
>> Sto trovando che molti siti e blog hanno un problema uguale al mio.
>> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di parole viene visualizzata la pagina 
>> precedente ma con tutta la schifezza aggiunta dopo.
>> Ma si capisce meglio dall'esempio:
>> http://my.jetscreenshot.com/5512/20160926-2t9t-37kb.jpg
>> 
>> -- 
>> Greg
>
> Non è un problema, è la pagina 404 senza scritto 404.

No, non è questo.
Pure l'Ansa è raggiungibile a ansa.it + 3 barrette rovesciate, e la pagina 404 ce l'hanno, come ce l'ho io:
http://www.ansa.it///

Aranzulla per esempio cancella le barrette e restituiesce l'url pulita, se c'è, altrimenti 404

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21174

Il giorno lunedì 26 settembre 2016 14:55:53 UTC+2, Greg ha scritto:
> Il 26/09/16 11:51:15 fmigliori ha scritto:
> > Il giorno lunedì 26 settembre 2016 11:43:34 UTC+2, Greg ha scritto:
> >> Sto trovando che molti siti e blog hanno un problema uguale al mio.
> >> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di parole viene visualizzata la pagina 
> >> precedente ma con tutta la schifezza aggiunta dopo.
> >> Ma si capisce meglio dall'esempio:
> >> http://my.jetscreenshot.com/5512/20160926-2t9t-37kb.jpg
> >> 
> >> -- 
> >> Greg
> >
> > Non è un problema, è la pagina 404 senza scritto 404.
> 
> No, non è questo.
> Pure l'Ansa è raggiungibile a ansa.it + 3 barrette rovesciate, e la pagina 404 ce l'hanno, come ce l'ho io:
> http://www.ansa.it///
> 
> Aranzulla per esempio cancella le barrette e restituiesce l'url pulita, se c'è, altrimenti 404
> 
> -- 
> Greg

So di non aver centrato perfettamente la tua domanda, ma ti rispondo comunque.
Ci sono due livelli di errore 404.
Uno è quello invocato da apache (manipolabile con htaccess e vhost) che non trova 
un file fisico sul disco, l'altro è invocato dall'applicativo, php o altro, che dagli 
argomenti inviati non trova la pagina logica.
Nel secondo caso può fare due cose:
1. restituisce come output la pagina 404;
2. restituisce come output un header un errore 404, che può portare a un pagina 
sia fisica che logica.
Nel secondo caso troverai l'uri come lo gradisci te in quanto non è una rielaborazione del uri precedente.
A causa del mod_rewrite magari non è facile risalire a quale livello avvenga.
In entrambi casi non ci sono errori, ne problemi, per questo lo trovi in molti siti.

Per quanto riguarda ansa.it io non riesco più a raggiungerlo.
Che tu abbia esagerato con le '/'? :p
Infine una domanda retorica: ma davvero ci sono tutti questi utenti che guardano 
l'uri di un link? O che editano l'uri per cui senza mod_rewrite avrebbero problemi 
a consultare il sito?

Il mod_rewrite sarebbe da abolire perché stupido (e lì si alzò il flame dei flame). 

[toc] | [prev] | [next] | [standalone]

#21175

Il 26/09/2016 19:24:58 fmigliori ha scritto:

> Per quanto riguarda ansa.it io non riesco più a raggiungerlo.
> Che tu abbia esagerato con le '/'? :p

No, è sempre raggiungibile: http://www.ansa.it///

> Infine una domanda retorica: ma davvero ci sono tutti questi utenti che guardano 
> l'uri di un link? O che editano l'uri per cui senza mod_rewrite avrebbero problemi 
> a consultare il sito?

No, il punti,, il dubbio è che Google, i motori di ricerca, vedendo che la stessa pagina è raggiungibe per url diverse, 
magari le vedano come pagine duplicate, e in effetti non avrebbero torto: url diversa, contenuto identico.

Se tu provi con http://www.aranzulla.it/// riscrive url senza barre
Sto facendo vari tentativi da ieri ma senza riuscirci. Dovrei trovarmi una rguida for dummy di regex

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21176

Greg <greg@alicie.com> ha scritto:

CUT
> Sto facendo vari tentativi da ieri ma senza riuscirci. Dovrei trovarmi una
rguida for dummy di regex

http://www.marioconcina.it/blog/come-fare/guida-alle-espressioni-regolari-regex.html

[toc] | [prev] | [next] | [standalone]

#21181

On Monday, September 26, 2016 at 1:24:59 PM UTC-4, fmigliori wrote:
> Il mod_rewrite sarebbe da abolire perché stupido (e lì si alzò il flame dei
> flame).
>

Beh, non va mica usato per forza, se ne è fatto a meno per anni! :)

Come per tutti gli strumenti abbastanza potenti, se lo sai usare bene ti
risparmia lavoro, altrimenti ti ci puoi facilmente fare male. :)

Per inciso, specialmente se lo sai usare bene, avrai due, massimo tre, regole
per ogni sito, visto che far fare al webserver una caterva di regexp ogni
richiesta non mi pare una scelta tanto felice.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21177

On Monday, September 26, 2016 at 5:43:34 AM UTC-4, Greg wrote:
> Sto trovando che molti siti e blog hanno un problema uguale al mio.
> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di
> parole viene visualizzata la pagina 
> precedente ma con tutta la schifezza aggiunta dopo.
>

Per quanto riguarda "le barre": è giusto così, da specifiche "/" e "///" sono lo
stesso percorso. Per quanto riguarda gli URL di root, avere "/" e nulla idem.
Non avrai mai il problema di URL doppi, se è questo che ti preoccupa perché,
appunto, la risorsa puntata è per definizione la stessa.

Se non lo vuoi per motivi estetici (?!?) puoi fare match con gli slash alla
fine (qualcosa tipo ^([^/*])/*$ rewrite su \1) ma non vedo perché dovresti.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21179

Il 26/09/2016 21:42:31 fmassei@gmail.com ha scritto:
> On Monday, September 26, 2016 at 5:43:34 AM UTC-4, Greg wrote:
>> Sto trovando che molti siti e blog hanno un problema uguale al mio.
>> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di
>> parole viene visualizzata la pagina 
>> precedente ma con tutta la schifezza aggiunta dopo.
>> 
>
> Per quanto riguarda "le barre": è giusto così, da specifiche "/" e "///" sono lo
> stesso percorso. Per quanto riguarda gli URL di root, avere "/" e nulla idem.
> Non avrai mai il problema di URL doppi, se è questo che ti preoccupa perché,
> appunto, la risorsa puntata è per definizione la stessa.
>
> Se non lo vuoi per motivi estetici (?!?) puoi fare match con gli slash alla
> fine (qualcosa tipo ^([^/*])/*$ rewrite su \1) ma non vedo perché dovresti.
>
> Ciao!

Perchè pensavo fossero url diverse che potessero dare origine a duplicati

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21180

On Monday, September 26, 2016 at 4:31:32 PM UTC-4, Greg wrote:
> Il 26/09/2016 21:42:31 fmassei@gmail.com ha scritto:
> > On Monday, September 26, 2016 at 5:43:34 AM UTC-4, Greg wrote:
> >> Sto trovando che molti siti e blog hanno un problema uguale al mio.
> >> Se all'url di una pagina di aggiunge uno slash e poi un numero a piacere di
> >> parole viene visualizzata la pagina 
> >> precedente ma con tutta la schifezza aggiunta dopo.
> >> 
> >
> > Per quanto riguarda "le barre": è giusto così, da specifiche "/" e "///" sono
> > lo stesso percorso. Per quanto riguarda gli URL di root, avere "/" e nulla
> > idem. Non avrai mai il problema di URL doppi, se è questo che ti preoccupa
> > perché, appunto, la risorsa puntata è per definizione la stessa.
> >
> > Se non lo vuoi per motivi estetici (?!?) puoi fare match con gli slash alla
> > fine (qualcosa tipo ^([^/*])/*$ rewrite su \1) ma non vedo perché dovresti.
> >
> > Ciao!
> 
> Perchè pensavo fossero url diverse che potessero dare origine a duplicati
> 

Vai tranquillo.
Nel caso di dubbi per altri casi limite, magari non così immediati, RFC 3986,
alla sezione 3.3 c'è l'ABNF.

Ciao!

P.S. Magari c'è un RFC più recente, non ho controllato, il tal caso fatemelo
sapere.. in ogni caso il concetto sarà sempre quello :)

[toc] | [prev] | [next] | [standalone]

#21182

Il 26/09/2016 22:48:11 fmassei@gmail.com ha scritto:

>> Perchè pensavo fossero url diverse che potessero dare origine a duplicati
>> 
>
> Vai tranquillo.

Però mi accetta anche www.miosito.it/////questapaginasaramai
ossia qualsiasi lettera dopo le barrette. Pure questo è nelle specifihce?

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21183

On Monday, September 26, 2016 at 5:48:38 PM UTC-4, Greg wrote:
> Il 26/09/2016 22:48:11 fmassei@gmail.com ha scritto:
> 
> >> Perchè pensavo fossero url diverse che potessero dare origine a duplicati
> >> 
> >
> > Vai tranquillo.
> 
> Però mi accetta anche www.miosito.it/////questapaginasaramai
> ossia qualsiasi lettera dopo le barrette. Pure questo è nelle specifihce?
> 

Sempre per la sezione di prima, lo URI è valido, avendo (con gli stessi nomi)
5 segment, di cui 4 path-empty. Per le regole di risoluzione sempre lo stesso
documento, sezione 5 (e ovviamente dicono che punta a "/questapaginasaramai").

Ciao!


P.S. io sto solo ripetendo le specifiche, che di sicuro apache o i bot di
Google seguono: non escludo però sia possibile trovare software scritto coi piedi
da chissà chi, che invece non lo faccia; per quello bisogna alzare le mani
(su chi ha scritto tale codice).

[toc] | [prev] | [next] | [standalone]

#21185

Il 27/09/16 00:10:30 fmassei@gmail.com ha scritto:

> Sempre per la sezione di prima, lo URI è valido, avendo (con gli stessi nomi)
> 5 segment, di cui 4 path-empty. Per le regole di risoluzione sempre lo stesso
> documento, sezione 5 (e ovviamente dicono che punta a "/questapaginasaramai").

Ho visto la documentazione tecnica, e purtroppo non è alla mia portata :(

> P.S. io sto solo ripetendo le specifiche, che di sicuro apache o i bot di
> Google seguono: non escludo però sia possibile trovare software scritto coi piedi
> da chissà chi, che invece non lo faccia; per quello bisogna alzare le mani
> (su chi ha scritto tale codice).

Ah non discuto di questo, io sono solo un onesto copiatore :)

In ogni caso, per farla semplice, il problema duplicati è risolto all'origine con il rel=canonical, ma avevo lo stesso 
la cusiosità di sapere come fa aranzulla a ripulire slash multipli a fine url mentre altri siti no

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21186

On 27/09/2016 12:50, Greg wrote:

> In ogni caso, per farla semplice, il problema duplicati è risolto
> all'origine con il rel=canonical, ma avevo lo stesso la cusiosità di
> sapere come fa aranzulla a ripulire slash multipli a fine url mentre
> altri siti no

Probabilmente con un plugin di wordpress. :D

C'è sicuramente il modo, lavorando di regexp su rewrite, ma oggi non ho 
molto tempo per fare test, sorry. :)

Bye.

[toc] | [prev] | [next] | [standalone]

#21187

On Tuesday, September 27, 2016 at 7:50:45 AM UTC-4, Greg wrote:
> la cusiosità di sapere come fa aranzulla a ripulire slash multipli a fine url
> mentre altri siti no
> 

Se usi apache qualcosa di questo tipo nello .htaccess dovrebbe andare (magari
ricontrolla le regexp, dovrei aver preso tutti i casi, ma non so):

# rimuovi slash spuri all'inizio (controllando sulla stringa di richiesta, che
# altrimenti hai l'URI ripulito in testa)
RewriteCond %{THE_REQUEST} ^[A-Z]+\s//+(.*)\sHTTP/[0-9.]+$ [OR]
RewriteCond %{THE_REQUEST} ^[A-Z]+\s(.*/)/+\sHTTP/[0-9.]+$
RewriteRule .* http://%{HTTP_HOST}/%1 [R=301,L]

# rimuovi dallo URI qualsiasi altro slash doppio
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 [R=301,L]

Non dovrebbe essere difficile far funzionare questa roba anche nel caso ti serva
un redirect fisso ad una pagina (come il tipico tutto allo index.php) o tu sia
sotto virtualhost, ma prima d'usarlo in produzione controlla.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21188

Il 27/09/2016 19:38:02 fmassei@gmail.com ha scritto:
> On Tuesday, September 27, 2016 at 7:50:45 AM UTC-4, Greg wrote:
>> la cusiosità di sapere come fa aranzulla a ripulire slash multipli a fine url
>> mentre altri siti no
>> 
>
> Se usi apache qualcosa di questo tipo nello .htaccess dovrebbe andare (magari
> ricontrolla le regexp, dovrei aver preso tutti i casi, ma non so):
>
> # rimuovi slash spuri all'inizio (controllando sulla stringa di richiesta, che
> # altrimenti hai l'URI ripulito in testa)
> RewriteCond %{THE_REQUEST} ^[A-Z]+\s//+(.*)\sHTTP/[0-9.]+$ [OR]
> RewriteCond %{THE_REQUEST} ^[A-Z]+\s(.*/)/+\sHTTP/[0-9.]+$
> RewriteRule .* http://%{HTTP_HOST}/%1 [R=301,L]
>
> # rimuovi dallo URI qualsiasi altro slash doppio
> RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
> RewriteRule . %1/%2 [R=301,L]
>
> Non dovrebbe essere difficile far funzionare questa roba anche nel caso ti serva
> un redirect fisso ad una pagina (come il tipico tutto allo index.php) o tu sia
> sotto virtualhost, ma prima d'usarlo in produzione controlla.
>
> Ciao!

Questa funziona, grazie :)
Ma è difficile anche solo leggerla, non dico capirla.
Domani voglio provare a decifrarla con la tabella dei simboli davanti

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21189

On Tuesday, September 27, 2016 at 5:13:32 PM UTC-4, Greg wrote:
> Il 27/09/2016 19:38:02 fmassei@gmail.com ha scritto:
> > Se usi apache qualcosa di questo tipo nello .htaccess dovrebbe andare (magari
> > ricontrolla le regexp, dovrei aver preso tutti i casi, ma non so):
> >
> > <snip>
> 
> Questa funziona, grazie :)
> Ma è difficile anche solo leggerla, non dico capirla.
> Domani voglio provare a decifrarla con la tabella dei simboli davanti
> 

Figurati :)
A leggere queste regexp con i simboli davanti è facile, non ci sono cose strambe
dentro: facci sapere se, come molto probabile, trovi qualche errore!

Ciao!

[toc] | [prev] | [next] | [standalone]

#21190

Il 28/09/16 03:49:49 fmassei@gmail.com ha scritto:
>>Questa funziona, grazie :)
>> Ma è difficile anche solo leggerla, non dico capirla.
>> Domani voglio provare a decifrarla con la tabella dei simboli davanti
>> 
>
> Figurati :)
> A leggere queste regexp con i simboli davanti è facile, non ci sono cose strambe
> dentro: facci sapere se, come molto probabile, trovi qualche errore!
>
> Ciao!

Allora vorrebbe dire che son diventato bravo :)
Una cosa che trovo è lo scope del parametro L.
Non fare altri revwirte per questa url, credo significhi, ma si riferisce solo a quella rewritecond oppure a tutte le 
successive?

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#21194

On Wednesday, September 28, 2016 at 4:23:48 AM UTC-4, Greg wrote:
> Una cosa che trovo è lo scope del parametro L.
> Non fare altri revwirte per questa url, credo significhi, ma si riferisce solo
> a quella rewritecond oppure a tutte le successive?
> 

Quando c'è un match, se la rule ha [L] non vengono controllate le altre
conditions successive: si interrompe il processo (tipo "break" in PHP per capirci,
come dice la documentazione di apache,
http://httpd.apache.org/docs/current/rewrite/flags.html#flag_l).

Ciao!

[toc] | [prev] | [next] | [standalone]

#21191

Il 28/09/16 03:49:49 fmassei@gmail.com ha scritto:

>> Questa funziona, grazie :)
>> Ma è difficile anche solo leggerla, non dico capirla.
>> Domani voglio provare a decifrarla con la tabella dei simboli davanti
>> 
>
> Figurati :)
> A leggere queste regexp con i simboli davanti è facile, non ci sono cose strambe
> dentro: facci sapere se, come molto probabile, trovi qualche errore!
>
> Ciao!

Allora vorrebbe dire che son diventato bravo
Una cosa che non trovo è lo scope del parametro L.
Non fare altri revwirte per questa url, credo significhi, ma si riferisce solo a quella rewritecond oppure a tutte le 
successive?

-- 
Greg

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web