Облачное хранилище Google возвращает старые данные

avatar
AAP
8 апреля 2018 в 10:24
739
1
4

Как это возможно? Что для одного и того же файла заголовки Date/Expires/Last-Modified сильно отличаются. Несмотря на то, что это поле было изменено сегодня (8 апреля), оно случайным образом возвращает 7 апреля, а затем 3 или 4 апреля!

curl -I http://storage.googleapis.com/myappname.appspot.com/config/config.json
HTTP/1.1 200 OK
X-GUploader-UploadID: AEnB2UoPjuz3v6i-RioExWbgl1JULi-FqGuXlljVXfQBCa3Xg5aSAGm9SslQu1m2I9ITSE6223FgsNjTiBMr4aS-QBeDumyv89n87pAnPpII7wffRZtCW70
Date: Sat, 07 Apr 2018 18:18:55 GMT
Expires: Sun, 07 Apr 2019 18:18:55 GMT
Last-Modified: Sat, 07 Apr 2018 17:25:44 GMT
ETag: "0a8411662813a125f999edad6079d7a5"
x-goog-generation: 1523121944356178
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 41487
Content-Type: application/json
x-goog-hash: crc32c=x7F/0g==
x-goog-hash: md5=CoQRZigToSX5me2tYHnXpQ==
x-goog-storage-class: STANDARD
Accept-Ranges: bytes
Content-Length: 41487
Server: UploadServer
Cache-Control: no-cache
Age: 57035

curl -I http://storage.googleapis.com/myappname.appspot.com/config/config.json
HTTP/1.1 200 OK
X-GUploader-UploadID: AEnB2UpWhRGTwxsME436eKKeSf507oBN4mfT9MZLknOVb92GdRmV-Cs8z8UTVDvoENIeN6fq9PL9A3HkRLgVIWJFhzfVM4Ysy4xz20ZS1Z-Ez18i1islc1o
Date: Wed, 04 Apr 2018 13:34:51 GMT
Expires: Thu, 04 Apr 2019 13:34:51 GMT
Last-Modified: Wed, 04 Apr 2018 07:14:23 GMT
ETag: "522c4e9f5f97873f930501b69da311cf"
x-goog-generation: 1522826063699049
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 40298
Content-Type: application/json
x-goog-hash: crc32c=ZhnEqg==
x-goog-hash: md5=UixOn1+Xhz+TBQG2naMRzw==
x-goog-storage-class: STANDARD
Accept-Ranges: bytes
Content-Length: 40298
Server: UploadServer
Cache-Control: Cache-Control:no-cache
Age: 333838

Он просто отказывается возвращать последние изменения, внесенные в этот файл, даже спустя много часов.

ОБНОВЛЕНИЕ: TRACEROUTE

traceroute to storage.googleapis.com (216.58.197.80), 30 hops max, 60 byte packets


1  192.168.0.1 (192.168.0.1)  1.544 ms  1.582 ms  1.973 ms
 2  10.247.0.1 (10.247.0.1)  5.637 ms  5.641 ms  5.624 ms
 3  broadband.actcorp.in (202.83.20.173)  5.609 ms  6.521 ms  6.524 ms
 4  broadband.actcorp.in (202.83.20.181)  6.520 ms  6.534 ms  6.941 ms
 5  broadband.actcorp.in (202.83.20.50)  11.394 ms  11.889 ms  11.881 ms
 6  72.14.194.18 (72.14.194.18)  45.704 ms  42.574 ms  42.644 ms
 7  * 108.170.253.113 (108.170.253.113)  42.576 ms *
 8  108.170.237.95 (108.170.237.95)  43.536 ms 108.170.236.197 (108.170.236.197)  45.852 ms  45.865 ms
 9  maa03s21-in-f16.1e100.net (216.58.197.80)  45.847 ms  43.914 ms  45.781 ms

На сегодняшний день (10 апреля) я все еще вижу:

Date: Wed, 04 Apr 2018 15:35:28 GMT
Expires: Thu, 04 Apr 2019 15:35:28 GMT
Last-Modified: Wed, 04 Apr 2018 07:14:23 GMT
ETag: "522c4e9f5f97873f930501b69da311cf"
x-goog-generation: 1522826063699049
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 40298
Content-Type: application/json
x-goog-hash: crc32c=ZhnEqg==
x-goog-hash: md5=UixOn1+Xhz+TBQG2naMRzw==
x-goog-storage-class: STANDARD
Accept-Ranges: bytes
Content-Length: 40298
Server: UploadServer
Cache-Control: Cache-Control:no-cache
Age: 528505

Однако в моей офисной сети я вижу более новую версию файла, но даже там она не соблюдает директиву "no-cache" и время от времени показывает устаревшие данные.

Источник
GalloCedrone
8 апреля 2018 в 11:19
0

Здравствуйте, вы получаете различные результаты, выдавая одну и ту же команду с одного и того же компьютера?

GalloCedrone
8 апреля 2018 в 11:23
0

Сам файл тоже другой или просто вереск?

AAP
8 апреля 2018 в 14:05
1

Это точно такой же файл и команда. Странно то, что когда я запускаю команду curl одну за другой, она возвращает два разных ответа!

AAP
8 апреля 2018 в 14:14
0

Да, содержимое возвращаемого файла отличается, потому что мы его обновили. Но 3 апреля показывает более старые результаты, 7 апреля показывает более новые, но по-прежнему не возвращает изменения, которые мы сделали сегодня (8 апреля)!

GalloCedrone
8 апреля 2018 в 14:28
0

Вы тестировали это поведение с разных терминалов/экземпляров? Если вы получаете доступ к объекту из своего браузера, вы получаете обновленный? Можете ли вы попробовать также с curl -H 'Cache-Control: no-cache' http://www.example.com?

AAP
8 апреля 2018 в 15:38
0

Другой терминал не имел значения. Браузер также показывает старую копию, как и «Общедоступная ссылка» в консоли Google Storage. Только касание фактического имени файла в консоли Google Storage показывает последний контент (я также могу получить последний контент через gsutil/code)

AAP
8 апреля 2018 в 15:40
0

curl -H 'Cache-Control:no-cache' http://... также возвращает старый контент

GalloCedrone
9 апреля 2018 в 15:23
0

Если вы заинтересованы, вы можете открыть приватную тему Google, и я рассмотрю ваш проект. Зарегистрируйте его здесь issuetracker.google.com/issues/new?component=187164 и разместите в комментарии ссылку (Отказ от ответственности: я работаю в службе поддержки Google Cloud Platform)

GalloCedrone
9 апреля 2018 в 15:24
0

Поместите туда (и сюда) трассировку к этому адресу, чтобы увидеть, всегда ли вы следуете одному и тому же пути.

AAP
10 апреля 2018 в 18:24
0

Спасибо, Галло, ценю вашу помощь. Я представил вопрос. Маршрут трассировки добавлен в исходное сообщение.

Sneha
12 апреля 2018 в 03:17
1

Я также сталкиваюсь с той же проблемой, пробовал много способов. С моей стороны это немного серьезно, так как наша финансовая система испытывает много проблем с получением последней версии счетов. Я надеюсь, что это скоро решится. @GalloCedrone вот ссылка на него issuetracker.google.com/issues/77842189

AAP
13 апреля 2018 в 05:16
0

Снеха, нам пришлось сделать экстренные обновления приложения, чтобы передать фиктивный параметр в конфиг ...?nocache=<timestamp>. С сегодняшнего утра я могу получать последний контент из той же конфигурации, но не уверен, как долго это будет длиться.

GalloCedrone
20 апреля 2018 в 10:07
0

@Sneha и APP, вы все еще сталкиваетесь с этой проблемой или ее можно считать решенной и с вашей стороны?

AAP
20 апреля 2018 в 13:52
1

@GalloCedrone, да, я думаю, что это можно считать решенным с моей стороны (хотя мы все равно обновили наши приложения сейчас)

Sneha
22 апреля 2018 в 04:49
1

@GalloCedrone, да, это решено и с моей стороны ... Огромное спасибо !! 1-недельный кошмар наконец-то закончился :D ...

Ответы (1)

avatar
GalloCedrone
16 апреля 2018 в 07:58
0

Отказ от ответственности. Я работаю в службе поддержки Google Cloud Platform. Надеюсь, эта информация окажется для вас полезной.

В настоящее время группа инженеров знает об этой проблеме и в настоящее время изучает ее с высоким приоритетом.

Обратите внимание, что:

Проблема с кэшированием объектов Google Cloud Storage, помеченных параметром cache-control: no-cache, была решена по состоянию на 13:11 США/Тихоокеанского региона 11 апреля 2018 г. Объекты, отмеченные с помощью cache-control, которые могли быть кэшированы, могут быть затронуты до четверга 2018-04-19, но доступен обходной путь.

A обходной путь как было предоставлено:

  • Клиенты, использующие Cloud CDN: клиенты, у которых есть корзина в качестве серверной части для HTTP(S) Load Balancer, могут вручную удалить объекты из кэша, выполнив аннулирование кэша через gcloud или облачную консоль. Клиенты, не использующие Cloud CDN: включение Cloud CDN приведет к тому, что объекты будут обслуживаться из Cloud CDN в дальнейшем, что позволит обойти проблему, поскольку Cloud CDN использует другие настройки.