кэширование — различные ответы с использованием интерфейса CLI curl и функции PHP curl

В основном я пытаюсь получить результаты матчей по футболу в прямом эфире и добавить их в личную базу данных на моем сервере. Это работает почти так, как ожидалось, за исключением одного:

Я использую PHP-скрипт для автоматического извлечения партитуры и вставки ее в базу данных. Я использую сайт uefa.com в качестве источника. Позволь мне привести пример:

это http://www.uefa.com/under21/season=2017/matches/live/day=20/session=1/match=2016266/index.html путь для отслеживания текущей оценки. Эта страница обновляется каждую минуту с использованием этого файла JSON: http://www.uefa.com/livecommon/match-centre/cup=13/season=2017/day=20/session=1/match=2016266/feed/minute.json (позже упоминается как $ json_url). При использовании FireBug или аналогичных инструментов можно увидеть, что JSON, отвечающий на запрос HTTP GET (инициированный JS на странице), является «живым», его содержимое часто меняется. Однако при получении JSON через PHP (file_get_contents($json_url)), похоже, что ответ меняется только каждые пару минут; кажется как-то кешируется.

Я провел небольшое тестирование и анализ с HTTP-заголовками и прочим, и получил результат, используя linux cli завивать можно просто получить JSON без этого кеш-подобного явления.

Естественно, теперь я пытался добиться этого с помощью плагина cURL PHP, но — никакого эффекта по сравнению с ситуацией ранее. Теперь я сравнил, что эти два запроса cURL делают подробно и — они делают то же самое. Однако они получают разные заголовки HTTP:

Это вывод завиток -v $ json_url:

* About to connect() to www.uefa.com port 80 (#0)
*   Trying 95.100.248.114...
* connected
* Connected to www.uefa.com (95.100.248.114) port 80 (#0)
> GET /livecommon/match-centre/cup=13/season=2017/day=20/session=1/match=2016266/feed/minute.json HTTP/1.1
> User-Agent: curl/7.26.0
> Host: www.uefa.com
> Accept: */*
>
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: public, max-age=300, must-revalidate
< Content-Type: application/json
< Last-Modified: Wed, 07 Oct 2015 20:37:55 GMT
< ETag: "16ec79b401d11:0"< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Wed, 07 Oct 2015 21:57:53 GMT
< Content-Length: 285
< Connection: keep-alive
<
* Connection #0 to host www.uefa.com left intact
[JSON DATA...]
* Closing connection #0

А теперь тот, который прислал PHP-Curl:

* About to connect() to www.uefa.com port 80 (#0)
*   Trying 95.100.248.114...
* connected
* Connected to www.uefa.com (95.100.248.114) port 80 (#0)
> GET /livecommon/match-centre/cup=3/season=2016/day=20/session=1/match=2016266/feed/minute.json HTTP/1.1
User-Agent: curl/7.26.0
Host: www.uefa.com
Accept: */*

* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Length: 285
< Content-Type: application/json; charset=utf-8
< Expires: Wed, 07 Oct 2015 21:38:54 GMT
< Server: Microsoft-IIS/7.5
< X-AspNet-Version: 2.0.50727
< X-Accel-Cache-Control: max-age=600
< X-Powered-By: ASP.NET
< Date: Wed, 07 Oct 2015 21:28:54 GMT
< Connection: keep-alive
<
* Connection #0 to host www.uefa.com left intact
* Closing connection #0

(Обратите внимание, что даты в этих ответах не являются проблемой — это совпадение было закончено до того, как я проверил команды)

Я думаю Cache-Control: private в заголовке ответа HTTP второго блока проблема и она должна быть Cache-Control: public, max-age=300, must-revalidate как в первом; но я хочу знать, почему заголовки вообще разные! Насколько я понимаю, заголовки запроса точно такие же. Некоторые примечания к блоку php curl: я использовал самый простой запрос curl в PHP, но добавил curl_setopt($ch, CURLOPT_USERAGENT, 'curl/7.26.0'); в противном случае пользовательский агент не был включен с помощью curl.

Я на этом сошел с ума — кто-нибудь знает, что я делаю неправильно, или, по крайней мере, может объяснить, откуда взялась разница? Я ценю любую помощь!

0

Решение

Задача ещё не решена.

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]