Newsgroup: it.comp.www.php
Titolo: percorso file nell'url

<?php
 
$xml = new DOMDocument();
$xml->loadHTMLFile('
http://tmp.local/sub/2.php/a/b?x=9'
);
 
echo $xml->documentURI;
 
?>
 
Ed ottengo:
 
http://tmp.local/sub/2.php/a/b?x=9
 
 
Adesso se volessi avere solo il nome della directory (/sub), come posso 
fare?

 fare?
 
Tagli la stringa fino al primo slash singolo e poi ripeti l'operazione 
sulla stringa ottenuta.


E cosa ottengo?
E se ad esempio '2.php' non fosse un file ma un "brutto ed insolito" 
nome di una directory?
 
In pratica sto realizzando un browser automatizzato per fare dei test.
 
Nella pagina 
http://tmp.local/sub/2.php/a/b?x=9
 ci sono due link:
 
- < a href="a.html" >...< /a >
- < a href="b.html" >...< /a >
 
Il browser dopo aver estratto tali link, "dovrebbe" continuare a navigare su
 
http://tmp.local/a.html
 
 
e anche poi su
 
http://tmp.local/b.html
 
 
Ho detto "dovrebbe" perchè in effetti c'è il problema che i due nuovi 
link non vengono "composti" correttamente; manca infatti il segmento 'sub'.
In pratica il browser li dovrebbe comporre in questo modo:
 
http://tmp.local/sub/a.html
 
http://tmp.local/sub/b.html
 
 
Ma naturalmente per inserire tale segmento (la directory) il browser lo 
dovrebbe infatti estrarre dall'url iniziale.
 
Come si fa?

 Come si fa?
 
Naturalmente la prima parte dell'url (nome dell'host) è facilmente 
ottenibile:
 
$host = 'http://'.$_SERVER['SERVER_NAME'];
 
resta solo da separare la directory dal nome del file (2.php) che 
potrebbe essere 'sub', ma anche:
 
sub/1
sub/1/abc
sub/xyz/abc/de
ecc.

 nome di una directory?
 
Non puoi saperlo.
 
Un URI è uno Uniform Resource Identifier. E` un id, non un percorso a un 
file.
 
Il fatto che somigli a un path di un filesystem non lo rende tale. Quindi 
non hai file o directory, ma solo componenti: http è il protocollo, 
tmp.local è l'hostname, /sub/2.php/a/b è il path e x=9 è la query string.
 
Oltre questo non puoi sapere, e te lo devi inventare. :)
 
Se sei lato server puoi confrontare il path richiesto con il tuo 
filesystem e cercare di capire cosa l'utente ha chiesto, ma lato client, 
come stai facendo tu, non puoi.
 
Bye.

 come stai facendo tu, non puoi.
 
Potrebbe usare un crawler già noto, alla peggio mi sembra che wget o 
curl in mirroring con un limite al numero di salti gli dia già il 
contenuto che gli serve.


Non funzionerebbe, perché quello è un rewrite fatto dal webserver. 
Potrebbe anche non esserci la parte 2.php in mezzo, per esempio. A quel 
punto sarebbe un path completamente virtuale, senza traccia di 
corrispondenza col filesystem.
 
Tra l'altro lo intuiamo noi che 2.php sia un file perché lo sembra, ma 
potrebbe anche non esserlo. Per esempio su molti servizi REST si usa 
l'estensione per definire il tipo di file accettato in risposta, quindi 
se chiami
 
http://www.example.org/api/pippo.html
 
 
e
 
http://www.example.org/api/pippo.json
 
 
In realtà chiami lo stesso script lato server, ma il primo ti torna una 
pagina web, e il secondo un json.
 
Bye.

 corrispondenza col filesystem.
 
Da quello che ho capito lui sta implementando proprio un crawler in PHP, 
non ha bisogno di corrispondenza con fs.


Invece mi sa di si. Confrontare le porzioni di uri, con le porzioni del 
path locale (sul filesystem), mi sembra l'unico modo per ottenere ciò 
che chiedo: dove finisce il path reale, e dove inizia il nome del file 
(o il path virtuale)-
 
Cmq in tempi ormai remoti (quando ancora non c'era l'adsl) si usavano 
largamente programmi per scaricare pagine web, o interi siti.
Si dava in pasto un URL, e ad esempio l'applicazione scaricava tutti le 
pagine corrispondenti ai link (riferimenti href, src, ecc.) trovati 
nella pagina iniziale.
 
Ma come facevano tali software a comporre correttamente tali riferimenti?
Forse ci riuscivano perchè non c'era ancora largo uso di php, 
mascheramento dell'url, ecc.
Gli url puntavano in pratica a file reali, ed era facile capire che la 
parte dopo l'ultima slash '/' era il file, mentre quello che c'era prima 
(escludendo protocollo e nome dell'host) era la directory.
Tali applicativi al giorno d'oggi funzionerebbero?
 
Forse no... dovrei provarne qualcuno... se ancora ne esistono.

 riferimenti?
 
Semplicemente seguono i link, e fanno una richiesta HTTP per ogni link 
che trovano.
 
Passando sempre e comunque attraverso il server web, è lui che traduce le 
richieste in file sul server.
 
Questo è un crawler abbastanza grezzo in PHP, se vuoi prendere spunto.
Occhio che sicuramente ha un sacco di bug! ;)
 
$base = '
http://www.example.org
';
 
$urls = array();
$urls[$base] = $base;
 
for ($now = current($urls);
     (isset($now) && $now != "");
     $now = next($urls)
) {
 
  $debug == 1 && print $now.": \n";
  $original_file = file_get_contents($now);
  $stripped_file = strip_tags($original_file, "<a>");
 
  preg_match_all("/<a(?:[^>]*)href=\"([^\"]*)\"(?:[^>]*)>(?:[^<]*)<\/a>/
is", $stripped_file, $matches);
 
  // $matches[0] now contains the complete A tags; ex: <a 
href="link">text</a>
  // $matches[1] now contains only the HREFs in the A tags; ex: link
 
  foreach ($matches[1] as $url) {
    $debug == 1 && print "-> " .$url;
 
    if ( (substr($url,0,7) != "http://")
         && (substr($url,0,6) != "ftp://")
         && (substr($url,0,7) != "mailto:")
         && (strpos($url, "#") === false)
         && strpos($url, "://") === false
    ) {
      $url = $base.$url;
      $urls[$url] = $url;
    }
  }
}
 
Alla fine in $urls ti trovi tutti i link interni al sito.
 
Bye.

 Forse ci riuscivano perchè non c'era ancora largo uso di php, 
 
Non ci riuscivano, stai confondendo la risorsa con il file.
Il crawler che chiede /pippo.gif riceve una risposta e la salva come 
pippo.gif anche se sul server si chiama pluto.html .


Infatti adesso ricordo; aprivi pippo.gif e ne veniva fuori un file corrotto.

 corrotto.
 
L'estensione di un file non è legata al suo contenuto, un file HTML 
chiamato "pippo.gif" non è corrotto.


Si cioè volevo dire, viene interpretato (almeno in windows) in modo errato.
Logicamente il sistema pensa che sia una gif, mentre è un documento html.

 largamente programmi per scaricare pagine web, o interi siti.
 
 
 
Bhè, si fà anche ora (
http://www.linuxjournal.com/content/downloading-entire-web-site-wget
), nessun cliente ti ha mai chiesto di mettere il sito su CD? (versione statica, ovviamente)


Scusate la  domanda poco pertinente, ma quando io apro un sito, dopo 
qualche giorno viene indicizzato sui motori di ricerca.
Come fanno yahoo, google, virgilio... a sapere che su internet esiste un 
nuovo sito?


o ci pensa il tuo hosting o glielo dici tu, sui siti dei motori di 
ricerca c'è una sezione dove avverti che c'è un nuovo sito, dopo un paio 
di giorni il loro crawler lo indicizza.
da qui a fare del SEO ne passa :)
 
 
Ciao


 
non puoi, un uri può NON corrispondere ad un path sul filesystem, anzi 
nel 90% dei casi non corrisponde proprio,
a meno che parliamo di siti fatti eoni fa (10/15 anni fa) dove ogni uri 
corrispondeva un file all'interno del webserver, ma oggi un URI è 
soltanto una identificativo di una risorsa, la quale può trovarsi 
ovunque e può essere qualunque cosa.
 
www.sito.it/news/page/2
 non identifica il path ma la risorsa news, 
l'azione page con parametro 2, che possono essere fisicamente un solo 
script, n script, un singolo file, un immagine o qualsiasi cosa 
rappresenti quella risorsa.
 
l'unica cosa certa è il nome del dominio 
sito.it
 
 
Ciao


 
In realtà estrarre la directory mi serve solo se il server restituisce 
lo status 301.
 
Ad es.
http://abc/123
 
 
risponde
 
HTTP 1/1 301 Moved permanenty
Location: 
http://abc/123/
 
 
C'è la slash finale, e quindi so che è una dir. a cui posso aggiungere 
il file:
http://abc/123/file.php
 


 
In realtà estrarre la directory mi serve solo se il server restituisce 
lo status 301.
 
Ad es.
http://abc/123
 
 
risponde
 
HTTP 1/1 301 Moved permanenty
Location: 
http://abc/123/
 
 
C'è la slash finale, e quindi so che è una dir. a cui posso aggiungere 
il file:
http://abc/123/file.php
 
 
Bastava solo farsi guidare dagli header.

 o ci pensa il tuo hosting o glielo dici tu, sui siti dei motori di
 
L'hosting è così gentile?
Mi pare strano :-b

 
http://abc/123/file.php
 
 
No, non lo sai. :)
 
http://abc/123
 e 
http://abc/123/
 sono due URI diversi, e il server fa 
redirect per evitare che i motori di ricerca indicizzino due URI con lo 
stesso contenuto, penalizzandoli entrambe. E` una scelta del sistemista. 
 
Avrebbe potuto fare il contrario (reindirizzare da quello con barra a 
quello senza), quindi non è un parametro che puoi prendere in 
considerazione.
 
Bye.
 

 considerazione.
 
Si ma non vedo altra soluzione...
 
Ripeto il concetto:
 
Sono il browser ed ho appena aperto la pagina: http:://sito/abc
Tale pagina contiene un link che punta alla risorsa: a.html
 
Per aprire tale link come compongo il nuovo url?
 
Non c'è la slash finale, quindi desumo che 'abc' sia un file; quindi lo 
rimpiazzo col nuovo file 'a.html', e ne ricavo http:://sito/a.html
 
Secondo caso:
 
Sono il browser ed ho appena aperto la pagina: http:://sito/abc
Il server mi risponde con un 301 e mi indirizza (Location) su: 
http:://sito/abc/
Seguo la strada da lui indicata, e mi sposto su: http:://sito/abc/
Tale pagina contiene un link che punta alla risorsa: a.html
 
Per aprire tale link come compongo il nuovo url?
 
C'è la slash finale, quindi desumo che 'abc' sia una directory; quindi 
all'url corrennte mi limito soltanto ad aggiungere il nuovo file 
'a.html', e ne ricavo http:://sito/abc/a.html
 
Tale approccio non è corretto? O sto sbagliando?
I motori di ricerca non lavorano in questo modo?

 
e i documenti che suggerisce.


Quindi se la pagina contiene link relativi, ma l'header non contiene
    <BASE Href="
http://www.aviary.com/products/intro.html
">
 
il documento va considerato non conforme?
In tal caso comunque l'url di base sarà quello della pagina, giusto?

 In tal caso comunque l'url di base sarà quello della pagina, giusto?
 
È scritto in quel paragrafo che ho indicato, prima della regola 3) che 
citi c'è la 2).
C'è anche un esempio di documento senza BASE che è considerato non 
valido: un documento HTML integrato in una email che non ha l'elemento 
BASE e usa attributi href relativi è considerato non valido perché non 
ha un URI proprio da usare come base.


 
Bene in italiano è tutto chiaro, l'inglese... :-b