OVH Community, votre nouvel espace communautaire.

PHP : file_get_contents et HTTPS


syl.fabre
25/11/2012, 15h05
J'avais rencontré un problème similaire avec l'api de google maps. J'obtenais sans cesse des limites à cause de l'ip commune aux serveurs mutualisés. J'ai donc rajouté une api key qui était facultative ce qui m'a permis de contourner les limitations par api vers une limitation sur cette api key

Geoffrey C.
18/01/2012, 16h21
Hello,

Merci pour ta réponse cassiopee, j'avais effectivement suivi ces pages et mis ça de côté pour l'étudier ce week-end

Merci pour vos réponses, je pense que l'oAuth sera une réponse à mon problème.
Pour le moment la doc est redirigée, blackout anti-sopa oblige !

Bonne fin de journée à tous !

PS : Gaston, j'ai tenté avec CURL, même résultat, mêmes limitations.

Gaston_Phone
17/01/2012, 20h57
Citation Envoyé par Geoffrey C.
Je développe un petit quelque chose vraiment tout simple qui me permet de récupérer un fichier xml (.rss) distant pour en récupérer une partie du contenu, le formater et l'afficher dans une partie de mon site.

Pour cela, j'utilise la fonction PHP file_get_contents() qui me semble la plus appropriée.
Et avec CURL ?

ekozan
17/01/2012, 20h36
Citation Envoyé par cassiopee
la limite passe à 350 appels par heure
Vrai avec une identification par Oauth ( qui fait sauté la limite par ip ) après on cache le résultat et on le mes a jour tout les 30secondes et c'est bon

cassiopee
17/01/2012, 19h38
Citation Envoyé par Geoffrey C.
Les widgets que proposent twitter pour afficher le flux d'un utilisateur est soumis à cette même limite ? C'est ça que je ne comprends pas très bien.
Je t'avouerais ne pas connaître dans le détail la programmation de ces widgets.

(et je viens de regarder un peu le code JS de l'un d'entre eux : 3000 lignes
de Javascript imbuvable à force d'optimisations, ça ne donne pas envie )

Pas mal d'infos par là :

https://dev.twitter.com/docs/rate-limiting

https://dev.twitter.com/docs/rate-limiting/faq

A priori, les limites sont les mêmes, seules certaines actions/requêtes ne sont pas limitées.


Quelques pistes supplémentaires par là :

https://dev.twitter.com/docs/streaming-api/user-streams

https://dev.twitter.com/docs/streaming-api/site-streams

mais je ne sais pas si ça peut répondre à tes besoins ?

Geoffrey C.
17/01/2012, 18h47
Super !

Merci pour cette réponse.
J'ai trouvé les infos sur la doc Twitter également.

Les widgets que proposent twitter pour afficher le flux d'un utilisateur est soumis à cette même limite ? C'est ça que je ne comprends pas très bien.

J'ai l'impression que mon projet de proposer un script sans JS et avec gestion d'un cache tombe à l'eau. J'ai un peu de mal à comprendre ce système de limite.

Je vais y réfléchir.

Merci pour ton implication

cassiopee
17/01/2012, 17h40
Ce qui est étrange c'est qu'un simple :

Code PHP:
$buffer file_get_contents("https://twitter.com");
print 
$buffer
passe sans problème mais pas l'URL que tu indiques (et pareil pour n'importe
quel compte Twitter), de même si on n'utilise pas le 'https' mais le 'http'
tout court, on obtient le même 'Bad request'.

En fait, il y a des limites ("rate limits") dans le nombre d'appels à Twitter.

Je croyais que c'était "pas plus de N appels à telle URL de tel compte Twitter"
mais il existe, en plus, une limite "par adresse IP de demandeur",
or on peut imaginer que l'adresse IP d'un système mutualisé d'OVH doit être
quasiment en permanence au dessus de ces limites ?

(pas plus de 150 appels par heure et par adresse IP pour une connexion
non authentifiée, la limite passe à 350 appels par heure pour une connexion
authentifiée mais pas sûr que ça suffise en l'occurence)

Geoffrey C.
17/01/2012, 16h58
Bonjour et merci pour cette réponse.

Je ne pense pas que ce soit un problème temporaire, ou alors c'est que les chinois ont encore sévi car le souci persiste.

Je viens de refaire quelques essais mais j'ai toujours cette erreur.

:s
Merci et bonne fin de journée.

cassiopee
16/01/2012, 13h26
Cf là sans doute : http://forums.ovh.com/showthread.php?t=76480

Geoffrey C.
15/01/2012, 23h19
Bonsoir à tous,


Je développe un petit quelque chose vraiment tout simple qui me permet de récupérer un fichier xml (.rss) distant pour en récupérer une partie du contenu, le formater et l'afficher dans une partie de mon site.

Pour cela, j'utilise la fonction PHP file_get_contents() qui me semble la plus appropriée.

J'effectue donc mes tests en local, comme tout développeur, et je me rends compte que tout roule. Je mets mon module en ligne, serveur mutualisé perso chez OVH, et là, c'est le drame.

Je vais chercher le fichier en protocole HTTPS, comme par exemple ce type de fichier : https://twitter.com/statuses/user_ti...tt.rss?count=2
Et il semble que ma méthode, très basique, ne fonctionne pas (je n'utilise vraiment rien d'autres qu'un simple file_get_contents()).

J'ai lu qu'il fallait que OpenSSL soit activé, mais après vérification, c'est bien le cas chez OVH...

J'ai tenté autre chose en ajoutant un contexte en paramètre à la fonction, mais j'ai peur de mal l'utiliser.

Code PHP:
$opts = array(
        
'https'=>array(
    
'method'=>"GET",
    
'header'=>"Content-Type: text/html; charset=utf-8"
    
)
);
    
$context stream_context_create($opts);    
    
$string file_get_contents$filenull$context );
?>
Ces quelques lignes me retournent une erreur, voici le header : HTTP/1.0 400 Bad Request.
Avec ou sans options, j'obtiens la même chose.

Vous auriez une idée de ce qui peut poser problème ?

Merci merci