problema con http e variabili php

Ciao a tutti, vorrei esporvi un mio (ma anche di molti altri italiani) problema. Io ho un sito web destinato ad una stazione meteo
http://www.meteoacquavivaba.altervista.org
e ho anche un dominio altervista
http://www.meteoacquaviva.it

Quel sito è formato da un template Saratoga;
esso si avvale di un file php, il file wu-forecast.php, che preleva delle previsioni meteo da un sito web (Wunderground) e le riporta nel mio sito. Soltanto che c'è un problema: la nuova versione del file php che comprende JSON mostra incompatibilità solo con i server altervista.
Così ho aperto un thread nel forum del template e mi hanno risposto che dipende da altervista. Ecco cosa mi hanno risposto (traducendo dall'inglese)

Ok, penso di aver isolato il problema con wu-forecast.php e altervista.org
Usando questo per accedere a wunderground (che fa le previsioni meteo) sul mio sito altervista di prova

   if(preg_match('|altervista.org|i',$_SERVER['SERVER_NAME'])) {
     $Status .= "<!-- using file_get_contents() for altervista.org site -->\n";
    $opts = array(
      'http'=>array(
        'method'=>"GET",
        'protocol_version' => 1.1,
        'timeout' => $numberOfSeconds,
        'header'=>"Cookie: Units=metric;\r\n" .
                  "Cache-control: no-cache,max-age=0\r\n" .
                  "User-agent: PHP,WU-forecast.php,saratoga-weather.org\r\n" .
                  "Connection: close\r\n"
                 // "User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"
      )
    );

     $context = stream_context_create($opts);
     $Status .= "<!-- request context\n".print_r($opts,true)." -->\n";
     $content = file_get_contents($url,false,$context);
     $headers = implode("\r\n",$http_response_header);
     $xml = $headers . "\r\n\r\n" . $content; 
     $Status .= "<!-- headers returned\n".$headers." -->\n"; 

Ottengo questo

<!-- WU URL: http://www.wunderground.com/q/zmw:00000.39.WTERA -->
<!-- loading from http://www.wunderground.com/q/zmw:00000.39.WTERA. -->
<!-- using file_get_contents() for altervista.org site -->
<!-- request context
Array
(
    [http] => Array
        (
            [method] => GET
            [protocol_version] => 1.1
            [timeout] => 10
            [header] => Cookie: Units=metric;
Cache-control: no-cache,max-age=0
User-agent: PHP,WU-forecast.php,saratoga-weather.org
Connection: close

        )

)
 -->
<!-- headers returned
HTTP/1.0 200 OK
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Date: Mon, 16 Jun 2014 22:13:26 GMT
Pragma: no-cache
Server: Apache/1.3.42 (Unix) PHP/5.3.2
Content-Type: text/html; charset=UTF-8
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Set-Cookie: ASC=1402956806:1; path=/; expires=Fri, 01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
Set-Cookie: rc=%2C00000.WTERA; path=/; expires=Sat, 15-Jun-2019 22:13:27 GMT; domain=.wunderground.com
Set-Cookie: DT=1402956806:11169:365-o3; path=/; expires=Fri, 01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
X-CreationTime: 0.367 -->
<!-- RC=200 OK, bytes=273185 -->
<!-- saved cache to ./WU-forecast-12-en.txt (273185 bytes) -->
<!-- using charsetInput='UTF-8' charsetOutput='ISO-8859-1' doIconv='1' doRTL='' -->

Usando invece lo stesso codice sul mio server XAMPP ho

<!-- WU-forecast.php (ML) Version 2.06 - 16-Jun-2014 on PHP 5.4.4 -->
<!-- WU URL: http://www.wunderground.com/q/zmw:00000.39.WTERA -->
<!-- loading from http://www.wunderground.com/q/zmw:00000.39.WTERA. -->
<!-- using file_get_contents() for altervista.org site -->
<!-- request context
Array
(
    [http] => Array
        (
            [method] => GET
            [protocol_version] => 1.1
            [timeout] => 10
            [header] => Cookie: Units=metric;
Cache-control: no-cache,max-age=0
User-agent: PHP,WU-forecast.php,saratoga-weather.org
Connection: close

        )

)
 -->
<!-- headers returned
HTTP/1.1 200 OK
Date: Mon, 16 Jun 2014 22:25:43 GMT
Server: Apache/1.3.42 (Unix) PHP/5.3.2
Cache-control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
X-CreationTime: 1.318
Set-Cookie: ASC=1402957543:1; path=/; expires=Fri, 01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
Set-Cookie: rc=%2C00000.WTERA; path=/; expires=Sat, 15-Jun-2019 22:25:45 GMT; domain=.wunderground.com
Set-Cookie: DT=1402957543:14342:365-g10; path=/; expires=Fri, 01-Jan-2020 00:00:00 GMT; domain=.wunderground.com
Connection: close
Content-Type: text/html; charset=UTF-8 -->
<!-- RC=200 OK, bytes=279887 -->
<!-- saved cache to ./WU-forecast-12-en.txt (279887 bytes) -->
<!-- using charsetInput='UTF-8' charsetOutput='ISO-8859-1' doIconv='1' doRTL='' -->
<!-- processing JSON entries for forecast -->
<!-- rawJSON size is 175798 bytes -->
<!-- Debug: saved JSON cache to ./WU-forecast-12-en-json.txt (175659 bytes) -->
<!-- json_decode returns  - No errors -->

Che è la risposta "giusta" che anche altervista dovrebbe dare
Se lo cambio e forzo una richiesta http/1.0, ottengo lo stesso risultato che mi dà altervista

Nota che ho specificato HTTP/1.1 come protocollo, ma la risposta ritorna come HTTP/1.0 attraverso i server altervista.
Il quale è errato ... deve esserci qualche proxy server di altervista che sta modificando la richiesta e la sta forzando al formato HTTP/1.0 prima di darla a Wunderground per il processing, e che è ciò che deve essere fixato con altervista.

Mostra loro questo post e chiedigli di NON modificare le richieste HTTP/1.1 di default alle richieste HTTP/1.0 per file(),file_get_content() o processing con fconnect()/fread() per gli strams HTTP (trad.originale:Show them this post and ask them to NOT MODIFY HTTP/1.1 requests to default to HTTP/1.0 requests for file(),file_get_content() or processing with fconnect()/fread() for HTTP streams.)

Best regards,
Kim

Questo è quanto. Spero ci sia una soluzione, perchè la maggiorparte degli italiani che usa quel template per la meteo usa altervista.

Grazie in anticipo,
Giacomo

Kim chiede se potreste mettere in whitelist http://*.weatherunderground.com e http://*.wunderground.com in modo che possano passare sotto proxy inalterati

[saitfainder]

Basta sbloccare le connessioni server-to-server seguendo la procedura sul pannello.

Salve, ho già l'opzione: "Collegamento esterno senza restrizioni"

Kim dice:

Il problema è con la connessione server-to-server dal LORO (di altervista) server a Wunderground. Quella connessione è probabilmente filtrata da un dispositivo proxy-di sicurezza gestido da LORO, il quale cambia la richiesta HTTP/1.1 a HTTP/1.0 e poi la passa a Wunderground. Alternativamente, potrebbe essere il loro setup PHP che sta forzando tutte le richieste HTTP ad usare HTTP/1.0. In entrambi i casi, è qualcosa che devono fixare gli amministratori di sistema di altervista.org. La richiesta HTTP/1.1 dovrebbe passare a qualunque server di destinazione (se hai attivato ciò con il tuo account), o ai domini presenti nella loro Whitelist.

Potrebbe essere fixato ciò?

Kim dice:


Potrebbe essere fixato ciò?

Si anche io Ho parecchi script che hanno smesso di funzionare per questo problema.......
Speriamo che lo fixate.......

----up!-----

[saitfainder]

Perché è errato HTTP 1.0? Su qualche porta fai le connessioni?

The WeatherUnderground website responds differently if the request is made using HTTP/1.0 protocol. It does not return the same complete page as when HTTP/1.1 protocol is used. Port 80 is used in all requests. The only usable response from WeatherUnderground is when HTTP/1.1 protocol is used. Please stop forcing the use of HTTP/1.0 for requests.

----

Il sito web Wunderground risponde differentemente ( in peggio ) se la richiesta è fatta usando il protocollo HTTP/1.0. Esso non restituisce la stessa pagina completa rispetto a quando viene usato il protocollo HTTP/1.1. La porta 80 è usata in tutte le richieste. L'unica risposta utilizzabile da Wunderground è quando viene usato il protocollo HTTP/1.1. Per favore, se potete non forzare l'uso di HTTP/1.0 per le richieste, grazie.

[saitfainder]

Non sarà possibile modificare questo comportamento. Le connessioni verso l'esterno passano attraverso un proxy HTTP che è lì a impedire abusi e problemi per tutta la community a causa dei soliti pochi malintenzionati. L'unico modo sarebbe una connessione via HTTPS alla stessa API, in quel caso il comportamento è diverso.

Non sarà possibile modificare questo comportamento. Le connessioni verso l'esterno passano attraverso un proxy HTTP che è lì a impedire abusi e problemi per tutta la community a causa dei soliti pochi malintenzionati. L'unico modo sarebbe una connessione via HTTPS alla stessa API, in quel caso il comportamento è diverso.

Salve lo capisco, ma non c'è modo di aggiungere nella whitelist del proxy soltanto questi due?
http://*.weatherunderground.com e http://*.wunderground.com
Stanno saltanto tutti i siti degli italiani che hanno una stazione meteo e che usano altervista!

[meteotaranto2]

Mi aggiungo anche io...

so che per voi è difficile modificare la whitelist del proxy, ma per colpa vostra molte pesone, stanno avendo MOLTI E DICO MOLTI problemi. Ora, non voglio dare la colpa a te, ma almeno che si riuscisse a fare qualcosa. Se non si può fare ciò che detto prima, aimhè l'unica soluzine è qulla di cambiare provider.
Cordiali Saluti

Ma vi rendete conto?
"Per colpa vostra"?
Cosa AV non vi sta fornendo contrariamente a quanto stipulato in fase di sottoscrizione? Per caso nel contratto con l'utente finale c'è scritto qualcosa in merito?
Adesso, se il servizio offerto ti sta bene, lo usi. Se non ti sta bene, al massimo chiedi se sia possibile una modifica. Ma la richiesta può essere accettata come può non esserlo. Punto. Nulla di più è dovuto.
Poi una questione tecnica, non si tratta di white o black list. Una volta sbloccate le connessioni, tutti i siti sono in white list, solo che il proxy, a prescindere dal colore del sito, usa il protocollo 1.0 e non 1.1

Ma vi rendete conto?
"Per colpa vostra"?
Cosa AV non vi sta fornendo contrariamente a quanto stipulato in fase di sottoscrizione? Per caso nel contratto con l'utente finale c'è scritto qualcosa in merito?
Adesso, se il servizio offerto ti sta bene, lo usi. Se non ti sta bene, al massimo chiedi se sia possibile una modifica. Ma la richiesta può essere accettata come può non esserlo. Punto. Nulla di più è dovuto.
Poi una questione tecnica, non si tratta di white o black list. Una volta sbloccate le connessioni, tutti i siti sono in white list, solo che il proxy, a prescindere dal colore del sito, usa il protocollo 1.0 e non 1.1

Vplaza ci scusi.... Qui c'è un thread in inglese se vuole. Secondo lei cosa potremmo - si potrebbe fare? Per noi è un grave problema, dato che quello script occupa anche parte della home...
Sono in collegamento con il thread che le ho indicato, dunque quale risposta dovrei comunicargli?
Grazie,

Giacomo

Tutto quello che potevate fare lo avete fatto.
Avete chiesto se fosse possibile modificare la configurazione. Vi è stato risposto che non è possibile farlo. Almeno al momento.
Da qui ad accusare AV ne passa. AV propone un servizio, coi suoi pro e i suoi contro. Ma è un servizio chiavi in mano. Se quello che viene offerto soddisfa i miei requisiti lo prendo altrimenti vado altrove. Non c'è altra soluzione.
Non posso però accusare AV perchè i miei servizi non funzionano, se questi non erano previsti dall'accordo. Quindi recrimino se non mi danno la versione 5.3 di PHP (promessa) ma nulla posso recriminare se non girano gli script ASP. Non importa se in ASP ci ho fatto un megaprogetto da 1000000000 di dollari e che la mancanza del suo supporto da parte di AV mi privi di questo introito. Non era previsto e non c'è.

Tutto quello che potevate fare lo avete fatto.
Avete chiesto se fosse possibile modificare la configurazione. Vi è stato risposto che non è possibile farlo. Almeno al momento.
Da qui ad accusare AV ne passa. AV propone un servizio, coi suoi pro e i suoi contro. Ma è un servizio chiavi in mano. Se quello che viene offerto soddisfa i miei requisiti lo prendo altrimenti vado altrove. Non c'è altra soluzione.
Non posso però accusare AV perchè i miei servizi non funzionano, se questi non erano previsti dall'accordo. Quindi recrimino se non mi danno la versione 5.3 di PHP (promessa) ma nulla posso recriminare se non girano gli script ASP. Non importa se in ASP ci ho fatto un megaprogetto da 1000000000 di dollari e che la mancanza del suo supporto da parte di AV mi privi di questo introito. Non era previsto e non c'è.

Vabbè come non detto grazie lo stesso...

[saitfainder]

Salve lo capisco, ma non c'è modo di aggiungere nella whitelist del proxy soltanto questi due?

La whitelist non centra nulla perché i domini non sono bloccati.

Invece, come detto dall'admin dello script, hanno deciso ad un certo punto di far comportare diversamente l'API in base alla versione HTTP usata e quindi hanno reso incompatibile Altervista con quel servizio. Da parte nostra il comportamento del proxy (che va benissimo per tutti gli altri servizi che usano la porta 80) non è previsto che venga modificato.

La whitelist non centra nulla perché i domini non sono bloccati.

Invece, come detto dall'admin dello script, hanno deciso ad un certo punto di far comportare diversamente l'API in base alla versione HTTP usata e quindi hanno reso incompatibile Altervista con quel servizio. Da parte nostra il comportamento del proxy (che va benissimo per tutti gli altri servizi che usano la porta 80) non è previsto che venga modificato.

Va bene grazie lo stesso per il supporto tecnico, però mi vedo purtroppo costretto a rivolgermi ad un servizio a pagamento di hosting

Ok anche io ho lo stesso problema,magari nel contratto si potrebbe specificare questo problema almeno un utente si comporta se conviene registrarsi o meno su AV.Sonom costretto anche io di abbandonare AV mi spiace,ma essendo una stazione meteo certificata non posso avere di questi problemi.

[saitfainder]

Nel contratto non c'è alcuna menzione delle connessioni server-to-server, si tratta di un servizio extra, che in più mettiamo a disposizione gratuitamente. Mi dispiace che nel vostro caso non corrisponda alle aspettative, ma non siamo nelle condizioni di poter andare incontro a tutte le possibili necessità.

Inoltre, in generale, Altervista è un servizio gratuito, quindi è possibile testare le funzionalità e poi decidere se rimanere con noi.