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

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

path locali è path remoti

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

Contents

  path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 17:56 +0100
    Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 09:34 -0800
      Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-22 19:39 +0100
        Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 10:58 -0800
          Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 21:48 +0100
            Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 13:00 -0800
              Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 22:27 +0100
      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 21:27 +0100
        Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 12:49 -0800
          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-22 22:32 +0100
            Re: path locali è path remoti fmassei@gmail.com - 2017-11-22 15:08 -0800
              Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-23 00:19 +0100
                Re: path locali č path remoti fmassei@gmail.com - 2017-11-22 15:30 -0800
                  Re: path locali č path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 09:36 +0100
                  Re: path locali c path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-23 14:41 +0100
              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 09:32 +0100
                Re: path locali è path remoti fmassei@gmail.com - 2017-11-26 17:26 -0800
                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-27 18:09 +0100
                    Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-27 19:16 +0100
                      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-28 15:16 +0100
                        Re: path locali è path remoti fmassei@gmail.com - 2017-11-28 07:35 -0800
                          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-28 17:34 +0100
                        Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-28 23:48 +0100
                          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-29 11:02 +0100
                            Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-29 14:32 +0100
                              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-29 15:27 +0100
                                Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-29 17:50 +0100
                                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-30 13:28 +0100
                                    Re: path locali è path remoti Leonardo Serni <lserni@gmail.com> - 2017-11-30 16:11 +0100
                                      Re: path locali � path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-30 17:10 +0000
                                        Re: path locali � path remoti fmassei@gmail.com - 2017-12-04 18:22 -0800
                                  Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-30 17:18 +0100
                                    Re: path locali è path remoti fmigliori <fmigliori@gmail.com> - 2017-11-30 08:41 -0800
    Re: path locali è path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-23 11:25 +0000
      Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 13:32 +0100
        Re: path locali è path remoti Alessandro Pellizzari <shuriken@amiran.it> - 2017-11-23 14:38 +0000
          Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-23 16:18 +0100
            Re: path locali è path remoti "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-11-24 17:59 +0000
              Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-25 12:18 +0100
                Re: path locali è path remoti alex <1j9448a02@lnx159sneakemail.com.invalid> - 2017-11-25 12:49 +0100

Page 2 of 2 — ← Prev page 1 [2]

#21815

On Tuesday, November 28, 2017 at 9:16:50 AM UTC-5, alex wrote:
> Non è che per caso anche gli sviluppatori di apache, php, mysql e 
> componenti relativi, abbiano qualcosa da scoprire e sistemare come si deve?
> Qualche spiegazione la vorrei piuttosto da loro...
> 
> $ sudo apt-get install apache2 phpX my-sql
> 
> e si dovrebbero aggiornare i vari software, ma senza alterare i file di 
> configurazione (php.ini, ecc.).
> Questi devono stare come gli ho impostati inizialmente. PUNTO
> 

Infatti così succede.

> Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?
> 

Evidentemente, le rare volte in cui succede che ti chieda di sovrascrivere
la configurazione, gli dici di sì.

> > (Io comincerei dal minacciare il sysadmin).
> 
> Prima di farlo userei prudenza (tanta), anche lui in fondo lavora con 
> strumenti costruiti da alcuni soggetti di cui ho già accennato...
>

Sinceramente, non ho mai avuto problemi di questo tipo.

Ciao!

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

#21816

Il 28/11/2017 16:35, fmassei@gmail.com ha scritto:
>> Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?
>>
> Evidentemente, le rare volte in cui succede che ti chieda di sovrascrivere
> la configurazione, gli dici di sì.
>

Possibile?
Cmq da ora in poi cercherò di stare più attento, tanto per diventare 
ancor più paranoico :)

>>> (Io comincerei dal minacciare il sysadmin).
>> Prima di farlo userei prudenza (tanta), anche lui in fondo lavora con
>> strumenti costruiti da alcuni soggetti di cui ho già accennato...
>>
> Sinceramente, non ho mai avuto problemi di questo tipo.

Forse perchè il computer che usi è posizionato con lo schermo verso 
ovest, o che gli aggiornamenti non devono essere mai fatti di lunedì, 
martedì e venerdì. Quando si ha a che fare con la tecnologia tutto è 
possibile :)

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

#21817

On Tue, 28 Nov 2017 15:16:47 +0100, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Non è che per caso anche gli sviluppatori di apache, php, mysql e 
>componenti relativi, abbiano qualcosa da scoprire e sistemare come si deve?
>Qualche spiegazione la vorrei piuttosto da loro...

>$ sudo apt-get install apache2 phpX my-sql

>e si dovrebbero aggiornare i vari software, ma senza alterare i file di 
>configurazione (php.ini, ecc.).
>Questi devono stare come gli ho impostati inizialmente. PUNTO

Non è proprio così. Innanzitutto alcune modifiche fra versioni (specie major)
possono modificare il php.ini principale; dovresti controllare il changelog.

E, comunque, tutti i file di configurazione dovrebbero essere backuppati, non
solo sulla macchina di produzione, ma anche sulla VM dove viene testata tutta
la procedura di upgrade.

>Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?

Una possibilità è che tu abbia un php.ini vecchio stile (tutto in un file), e
lo stesso per Apache. La tendenza adesso è di avere un file .ini, con le cose
che devono stare sempre a quel modo, e un file ".local.ini", o similare, dove
ci metti le tue personalizzazioni. Di regola, se la stessa variabile si trova
in tutti e due, conta quella del file locale.

Leonardo

-- 

Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

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

#21818

Il 28/11/2017 23:48, Leonardo Serni ha scritto:
>> e si dovrebbero aggiornare i vari software, ma senza alterare i file di
>> configurazione (php.ini, ecc.).
>> Questi devono stare come gli ho impostati inizialmente. PUNTO
> Non è proprio così. Innanzitutto alcune modifiche fra versioni (specie major)
> possono modificare il php.ini principale

Perchè?
Perchè modificare l'error-prepend-string?
Perchè?
Se si tratta di nuovi settings OK (che poi andrebbero semplicemente 
aggiunti all'apposito file ini), ma il resto dovrebbe restare immacolato.

> 
> E, comunque, tutti i file di configurazione dovrebbero essere backuppati, non
> solo sulla macchina di produzione, ma anche sulla VM dove viene testata tutta
> la procedura di upgrade.
> 

Su questo sono d'accordo, anche se, secondo quanto hai detto, 
bisognerebbe fare il ripristino dei file di configurazione dopo ogni 
upgrade, col rischio di distruggere le nuove opzioni (come accennato).

>> Se ciò non avviene è colpa mia? Ho sbagliato qualcosa? Che cosa?
> Una possibilità è che tu abbia un php.ini vecchio stile (tutto in un file), e
> lo stesso per Apache. La tendenza adesso è di avere un file .ini, con le cose
> che devono stare sempre a quel modo, e un file ".local.ini", o similare, dove
> ci metti le tue personalizzazioni. Di regola, se la stessa variabile si trova
> in tutti e due, conta quella del file locale.

Ho fatto qualche prova.

$ cat index.php
<?php // index.php of http://usb-test.local/
echo "error_prepend_string: ".ini_get('error_prepend_string');

$ cat .user.ini
error_prepend_string = "test2"

$ curl http://usb-test.local/
error_prepend_string:

Non dovrebbe comparire 'test2'?

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

#21819

On Wed, 29 Nov 2017 11:02:53 +0100, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>Su questo sono d'accordo, anche se, secondo quanto hai detto, 
>bisognerebbe fare il ripristino dei file di configurazione dopo ogni 
>upgrade, col rischio di distruggere le nuove opzioni (come accennato).

Non per forza, ma PUOI sempre fare il ripristino e sicuramente puoi fare un
compare.

>> Una possibilità è che tu abbia un php.ini vecchio stile (tutto in un file), e
>> lo stesso per Apache. La tendenza adesso è di avere un file .ini, con le cose
>> che devono stare sempre a quel modo, e un file ".local.ini", o similare, dove
>> ci metti le tue personalizzazioni. Di regola, se la stessa variabile si trova
>> in tutti e due, conta quella del file locale.

>Ho fatto qualche prova.

>$ cat index.php
><?php // index.php of http://usb-test.local/
>echo "error_prepend_string: ".ini_get('error_prepend_string');

>$ cat .user.ini
>error_prepend_string = "test2"

>$ curl http://usb-test.local/
>error_prepend_string:

>Non dovrebbe comparire 'test2'?

Perché il PHP di usb-test.local dovrebbe leggere un file chiamato ".user.ini"
nella home directory [1]?

Ancora ancora se fosse un .htaccess, e questo fosse attivato.

	php_value error_prepend_string 	"Settato localmente"

A proposito di .htaccess, una citazione dalla documentazione di Apache:

	In general, you should only use .htaccess files when you don’t have
	access to the main server configuration file.

	There is, for example, a common misconception that user authentication
	should always be done in .htaccess files, and, in more recent years,
	another misconception that mod_rewrite directives must go in .htaccess
	files. 

	This is simply not the case.

	You can put user authentication configurations in the main server
	configuration, and this is, in fact, the preferred way to do things.

Leonardo

[1] in teoria su Apache ci sarebbe la direttiva AccessFileName che... (pausa
    per spararsi in un piede) ...consentirebbe...

-- 

Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

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

#21820

Il 29/11/2017 14:32, Leonardo Serni ha scritto:
> On Wed, 29 Nov 2017 11:02:53 +0100, alex
> <1j9448a02@lnx159sneakemail.com.invalid> wrote:
> 
>> Su questo sono d'accordo, anche se, secondo quanto hai detto,
>> bisognerebbe fare il ripristino dei file di configurazione dopo ogni
>> upgrade, col rischio di distruggere le nuove opzioni (come accennato).
> 
> Non per forza, ma PUOI sempre fare il ripristino e sicuramente puoi fare un
> compare.
> 

E' che bisogna sempre lavorare (lavorare tanto).
Pazienza, tanto ci pagano :)

>> $ cat index.php
>> <?php // index.php of http://usb-test.local/
>> echo "error_prepend_string: ".ini_get('error_prepend_string');
> 
>> $ cat .user.ini
>> error_prepend_string = "test2"
> 
>> $ curl http://usb-test.local/
>> error_prepend_string:
> 
>> Non dovrebbe comparire 'test2'?
> 
> Perché il PHP di usb-test.local dovrebbe leggere un file chiamato ".user.ini"
> nella home directory [1]?
> 

echo ini_get('user_ini.filename');
visualizza
.user.ini

Pensavo c'entrasse qualcosa.

> Ancora ancora se fosse un .htaccess, e questo fosse attivato.
> 
> 	php_value error_prepend_string 	"Settato localmente"
> 

Oh ma questo sistema però funziona, molto bene :)

> A proposito di .htaccess, una citazione dalla documentazione di Apache:
> 
> 	In general, you should only use .htaccess files when you don’t have
> 	access to the main server configuration file.
> 
> 	There is, for example, a common misconception that user authentication
> 	should always be done in .htaccess files, and, in more recent years,
> 	another misconception that mod_rewrite directives must go in .htaccess
> 	files.
> 
> 	This is simply not the case.
> 
> 	You can put user authentication configurations in the main server
> 	configuration, and this is, in fact, the preferred way to do things.
> 
> Leonardo
> 
> [1] in teoria su Apache ci sarebbe la direttiva AccessFileName che... (pausa
>      per spararsi in un piede) ...consentirebbe...
> 

ok ok ok fermati :)

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

#21821

On Wed, 29 Nov 2017 15:27:31 +0100, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>> Perché il PHP di usb-test.local dovrebbe leggere un file chiamato ".user.ini"
>> nella home directory [1]?

>echo ini_get('user_ini.filename');
>visualizza
>.user.ini

>Pensavo c'entrasse qualcosa.

In effetti quasi. Ignoravo del tutto l'esistenza di questa bestemmia
all'interno del codice di PHP, e devo dire che stavo meglio prima.

http://php.net/manual/en/configuration.file.per-user.php

Ma vedo che funziona solo per alcune voci, tu magari volevi cambiare
qualcosa d'altro. Oppure stai usando apache2handler, ovvero PHP come
modulo Apache.

Una nota interessante che leggo:

	"If you are using Apache, use .htaccess files for the same effect."

	To clarify, this applies only to Apache module mode. If you put php
	directives in .htaccess on an Apache CGI/FastCGI server, this will
	bomb the server out with a 500 error. Thus, you unfortunately cannot
	create a config which caters for both types of hosting, at least not
	in any straightforward way.

E una altrettanto interessante che dovrei scriverci:

	Note that .user.ini starts with a dot, which makes it Unix invisible,
	but not with .ht, which is the invisibility rule on several Apache
	installations.
	Therefore, any .user.ini you set up will be readable by anyone; it
	is probably harmless, but let's not forget this.

Mi domando se uno uploadasse in una directory di upload statici (che
non a caso sono IL MALE) un file ".user.ini", ed in quel file avesse
inserito come "auto_prepend_file", un file .htpasswd... devo fare la
prova uno di questi giorni.

>> Ancora ancora se fosse un .htaccess, e questo fosse attivato.

>> 	php_value error_prepend_string 	"Settato localmente"

>Oh ma questo sistema però funziona, molto bene :)

Finché .htaccess è attivo in quella directory, sì ;-)

Leonardo

-- 

Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

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

#21823

Il 29/11/2017 17:50, Leonardo Serni ha scritto:
>> echo ini_get('user_ini.filename');
>> visualizza
>> .user.ini
>> Pensavo c'entrasse qualcosa.
> In effetti quasi. Ignoravo del tutto l'esistenza di questa bestemmia
> all'interno del codice di PHP, e devo dire che stavo meglio prima.
>
> http://php.net/manual/en/configuration.file.per-user.php
>
> Ma vedo che funziona solo per alcune voci, tu magari volevi cambiare
> qualcosa d'altro. Oppure stai usando apache2handler, ovvero PHP come
> modulo Apache.

Cioè si può usare in altri modi?
Quante cose che non so, e più imparo più ho da imparare (beati gli 
ignoranti) :D

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

#21824

On Thu, 30 Nov 2017 13:28:08 +0100, alex
<1j9448a02@lnx159sneakemail.com.invalid> wrote:

>> In effetti quasi. Ignoravo del tutto l'esistenza di questa bestemmia
>> all'interno del codice di PHP, e devo dire che stavo meglio prima.

>> http://php.net/manual/en/configuration.file.per-user.php

>> Ma vedo che funziona solo per alcune voci, tu magari volevi cambiare
>> qualcosa d'altro. Oppure stai usando apache2handler, ovvero PHP come
>> modulo Apache.

>Cioè si può usare in altri modi?

Sì: come CGI (ci sono dei pro e dei contro), e come FastCGI (anche qui ci
sono dei pro e dei contro).

Del resto anche Apache mi pare abbia due "modalità", prefork e mpm.

>Quante cose che non so, e più imparo più ho da imparare (beati gli 
>ignoranti) :D

Però, strada facendo ci si diverte, dài.

Leonardo

-- 

Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

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

#21827 — Re: path locali � path remoti

On 30/11/2017 15:11, Leonardo Serni wrote:

> Del resto anche Apache mi pare abbia due "modalità", prefork e mpm.

Per precisione, il "framework" di moduli si chiama mpm, mentre i moduli 
possono essere prefork (lancia un pool di processi), worker (lancia un 
pool di processi, ognuno con un pool di thread) e event (ehm... boh! una 
sorta di green threads?)

PHP funziona solo con prefork, a meno di non compilarlo senza il 
supporto per i componenti che non sono thread-safe.

Bye.

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

#21828 — Re: path locali � path remoti

On Thursday, November 30, 2017 at 12:11:01 PM UTC-5, Alessandro Pellizzari wrote:
> [..] event (ehm... boh! una sorta di green threads?)
> 

Gli "event" nascono qualche anno fa appoggiandosi ad una nuova API di
kernel e glib (epoll), estendendo le possibilità della classica select().
Oggigiorno praticamente ogni software che classicamente faceva R/W su
fds/sockets in un ciclo con select è passato alla "nuova versione".

A livello di performances danno il massimo su alti numeri di richieste
statiche di basso carico, e infatti sono usati principalmente da webservers
lightweight tipo boa o, nel caso di apache, quando questo è il suo compito
principale.

Ciao!

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

#21825

Il 29/11/2017 17:50, Leonardo Serni ha scritto:
>>> 	php_value error_prepend_string 	"Settato localmente"
>> Oh ma questo sistema però funziona, molto bene :)
> Finché .htaccess è attivo in quella directory, sì ;-)

Perdona ancora la mia ignoranza, .htaccess in che modo si può disattivare?

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

#21826

Il giorno giovedì 30 novembre 2017 17:20:46 UTC+1, alex ha scritto:
> Il 29/11/2017 17:50, Leonardo Serni ha scritto:
> >>> 	php_value error_prepend_string 	"Settato localmente"
> >> Oh ma questo sistema però funziona, molto bene :)
> > Finché .htaccess è attivo in quella directory, sì ;-)
> 
> Perdona ancora la mia ignoranza, .htaccess in che modo si può disattivare?

Con una ricerca 

https://duckduckgo.com/?q=apache2+htaccess+disable&t=osx&ia=qa

È conveniente disabilitarli e mettere le impostazioni direttamente nel vhost del sito (Ubuntu) o apache2.conf (resto del mondo), perché Apache diventa più veloce.

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

#21802

On 22/11/2017 16:56, alex wrote:

> $path1='/a/b/c';
> $path2='http://a/b/c';
> $path3='https://a/b/c';
> $path4='ftp://a/b/c';
> $path5='ssh:/a/b/c';

Quest'ultimo è sbagliato: "ssh://host/a/b/c"

Tutti gli URI hanno "://", puoi controllare quello.

Ma non è detto che siano remoti. Per esempio "file://" è locale.

E ce ne sono altri predefiniti (http://php.net/manual/en/wrappers.php) 
oltre a quelli che puoi definire da solo.

Credo dovresti ripensare quello che stai facendo.

Bye.

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

#21803

Il 23/11/2017 12:25, Alessandro Pellizzari ha scritto:
> On 22/11/2017 16:56, alex wrote:
>
>> $path1='/a/b/c';
>> $path2='http://a/b/c';
>> $path3='https://a/b/c';
>> $path4='ftp://a/b/c';
>> $path5='ssh:/a/b/c';
>
> Quest'ultimo è sbagliato: "ssh://host/a/b/c"
>

Non proprio
https://anticameradelcestino.wordpress.com/2009/01/08/backup-con-rsync-via-ssh/
(verso la fine dell'articolo)

>
> Ma non è detto che siano remoti. Per esempio "file://" è locale.
>

Vero.

> E ce ne sono altri predefiniti (http://php.net/manual/en/wrappers.php)
> oltre a quelli che puoi definire da solo.
>

Molto interessante, grazie 1000.

> Credo dovresti ripensare quello che stai facendo.

Effettivamente :)

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

#21805

On 23/11/2017 12:32, alex wrote:

> Il 23/11/2017 12:25, Alessandro Pellizzari ha scritto:

>>> $path5='ssh:/a/b/c';

>> Quest'ultimo è sbagliato: "ssh://host/a/b/c"

> Non proprio
> https://anticameradelcestino.wordpress.com/2009/01/08/backup-con-rsync-via-ssh/ 
> 
> (verso la fine dell'articolo)

Qui stiamo parlando di PHP e di come gestisce i path (per esempio per 
file_get_contents), e il formato è quello dell'URI.

Quella che linki è una guida per la shell usando direttamente ssh (rsync 
usa direttamente ssh), quindi logicamente i suoi "path" saranno in un 
formato che non richiede "ssh://" davanti, ma direttamente "user@host:path".

Bye.

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

#21806

Il 23/11/2017 15:38, Alessandro Pellizzari ha scritto:
>
> Qui stiamo parlando di PHP e di come gestisce i path (per esempio per
> file_get_contents), e il formato è quello dell'URI.
>
> Quella che linki è una guida per la shell usando direttamente ssh (rsync
> usa direttamente ssh), quindi logicamente i suoi "path" saranno in un
> formato che non richiede "ssh://" davanti, ma direttamente
> "user@host:path".

OK ti do ragione anche su questo :)
Ma cosa avevano in testa gli sviluppatori dei protocolli su internet, a 
cosa gli serviva la doppia slash?

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

#21807

alex <1j9448a02@lnx159sneakemail.com.invalid> ha scritto:

> Il 23/11/2017 15:38, Alessandro Pellizzari ha scritto:
> >
> > Qui stiamo parlando di PHP e di come gestisce i path (per esempio per
> > file_get_contents), e il formato è quello dell'URI.
> >
> > Quella che linki è una guida per la shell usando direttamente ssh (rsync
> > usa direttamente ssh), quindi logicamente i suoi "path" saranno in un
> > formato che non richiede "ssh://" davanti, ma direttamente
> > "user@host:path".
> 
> OK ti do ragione anche su questo :)
> Ma cosa avevano in testa gli sviluppatori dei protocolli su internet, a 
> cosa gli serviva la doppia slash?

comincia da qui:

https://tools.ietf.org/html/rfc3986

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

#21808

Il 24/11/2017 18:59, go_brexit_go ha scritto:
> alex <1j9448a02@lnx159sneakemail.com.invalid> ha scritto:
>
>> Il 23/11/2017 15:38, Alessandro Pellizzari ha scritto:
>>>
>>> Qui stiamo parlando di PHP e di come gestisce i path (per esempio per
>>> file_get_contents), e il formato è quello dell'URI.
>>>
>>> Quella che linki è una guida per la shell usando direttamente ssh (rsync
>>> usa direttamente ssh), quindi logicamente i suoi "path" saranno in un
>>> formato che non richiede "ssh://" davanti, ma direttamente
>>> "user@host:path".
>>
>> OK ti do ragione anche su questo :)
>> Ma cosa avevano in testa gli sviluppatori dei protocolli su internet, a
>> cosa gli serviva la doppia slash?
>
> comincia da qui:
>
> https://tools.ietf.org/html/rfc3986

eppure anni fa ricordo di aver letto che il creatore di http, ha ammesso 
che era un impiccio che si poteva evitare, ma dato che ormai gli 
standard sono quelli...

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

#21809

Il 25/11/2017 12:18, alex ha scritto:
>
> eppure anni fa ricordo di aver letto che il creatore di http, ha ammesso
> che era un impiccio che si poteva evitare, ma dato che ormai gli
> standard sono quelli...

http://forum.html.it/forum/showthread/t-1370452.html

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web