Фоновая интеллектуальная служба передачи и Amazon S3 - PullRequest
Новая
       29

Фоновая интеллектуальная служба передачи и Amazon S3

4 голосов
/ 06 февраля 2010

Я использую SharpBITS для загрузки файла с AmazonS3. 

> // Create new download job. BitsJob
> job = this._bitsManager.CreateJob(jobName, JobType.Download);
> // Add file to job.
> job.AddFile(downloadFile.RemoteUrl, downloadFile.LocalDestination);
> // Resume
> job.Resume();

Работает для файлов, которые не требуют аутентификации. Однако, как только я добавлю строку запроса аутентификации для запроса файла AmazonS3, ответ от сервера будет http state 403 -unauthorized. URL работает файл в браузере.

Вот HTTP-запрос от службы BIT: 

HEAD /mybucket/6a66aeba-0acf-11df-aff6-7d44dc82f95a-000001/5809b987-0f65-11df-9942-f2c504c2c389/v10/summary.doc?AWSAccessKeyId=AAAAZ5SQ76RPQQAAAAA&Expires=1265489615&Signature=VboaRsOCMWWO7VparK3Z0SWE%2FiQ%3D HTTP/1.1
Accept: */*
Accept-Encoding: identity
User-Agent: Microsoft BITS/7.5
Connection: Keep-Alive
Host: s3.amazonaws.com

Единственным отличием от веб-браузера является тип запроса. Firefox отправляет запрос GET, а BITS отправляет запрос HEAD. Есть ли проблемы с запросами Amazon S3 HEAD и проверкой подлинности строки запроса?

С уважением, Blaz

Ответы [ 2 ]

2 голосов
/ 29 июня 2010

Вы, вероятно, правы, что прокси - единственный способ обойти это. BITS использует запрос HEAD, чтобы получить длину контента и решить, хочет ли он разделить загрузку файла. Затем он выполняет запрос GET для фактического получения файла - иногда в целом, если файл достаточно мал, в противном случае с заголовками диапазона.

Если вы можете использовать прокси-сервер или другой трюк, чтобы дать ему какой-либо ответ на запрос HEAD, он должен отклеиться. Даже если запрос HEAD подделан с фиктивной длиной контента, BITS перейдет к GET. В подобном случае вы можете увидеть повторяющиеся запросы GET, потому что, если первый запрос GET возвращает длину содержимого, превышающую исходный запрос HEAD, BITS может решить: «О, чёрт, я все равно лучше разбить на части».

Учитывая это, я немного удивлен, что он недостаточно умен, чтобы восстановиться после ошибки 403 в запросе HEAD и все же перейти к GET. Каково реальное поведение работы? Вы пробовали смотреть его с помощью битсадмина / монитора? Если задание находится в состоянии временной ошибки, оно может делать это в течение примерно 20 минут, а затем в конечном итоге восстанавливаться.

1 голос
/ 13 января 2018

Перед началом загрузки BITS отправляет запрос HTTP HEAD на сервер, чтобы определить размер удаленного файла, временную метку и т. Д. Это особенно важно для BITS-передач на основе BranchCache и является причина, по которой поддержка HTTP HEAD на стороне сервера указана как требование HTTP для загрузок BITS .

При этом BITS обходит фазу запроса HTTP HEAD , сразу же отправляя запрос HTTP GET , если выполняется любое из следующих условий:

  1. Задание BITS настраивается с флагом BITS_JOB_PROPERTY_DYNAMIC_CONTENT .
  2. BranchCache отключен И задание BITS содержит один файл.

Обходной путь (1) является наиболее подходящим, поскольку он не влияет на другие передачи BITS в системе.

Для обходного пути (2) BranchCache можно отключить с помощью групповой политики BITS DisableBranchCache . Вам нужно будет выполнить команду «gpupdate» из командной строки с повышенными привилегиями после внесения любых изменений в групповую политику, иначе для вступления изменений в силу потребуется ~ 90 минут.

...