ექსპლუატაცია8 ოქტომბერი, 202611 წუთის საკითხავი

S3 path-style vs virtual-hosted URL-ები და რეგიონების ახსნა

რა არის S3-ის path-style და virtual-hosted მისამართი, რატომ იყენებს self-hosted endpoint-ები path-style-ს და ზუსტად სად არის ეს პარამეტრი ყველა ცნობილ SDK-სა და ხელსაწყოში.

0 მკითხველი

S3 კლიენტს bucket-ის სახელის ორიდან ერთ ადგილას ჩასმა შეუძლია. Path-style მას გზაში სვამს: https://s3.example.com/my-bucket/photo.jpg. Virtual-hosted სტილი მას ჰოსტის სახელში სვამს: https://my-bucket.s3.example.com/photo.jpg. Amazon მეორეს ამჯობინებს, და SDK-ების უმეტესობა მას ნაგულისხმევად ირჩევს, როცა AWS-ს ესაუბრება. თითქმის ყველა S3-თავსებად endpoint-ს, რომელიც AWS არ არის - self-hosted საცავს, პატარა პროვაიდერს, საცავის სერვერს ერთი დომენის უკან - პირველი სჭირდება, რადგან virtual-hosted მისამართს ყოველი bucket-ის სახელისთვის DNS ჩანაწერი და TLS სერტიფიკატი სჭირდება. თუ შენი კლიენტი არასწორ სტილზეა დაყენებული, მიიღებ DNS-ის შეცდომებს, სერტიფიკატის შეცდომებს ან "bucket not found"-ს, და გამოსწორება ერთი პარამეტრია. ეს პოსტი ხსნის ორივე სტილს, რას აკეთებს სინამდვილეში რეგიონის სახელი და სად ცხოვრობს ეს ერთი პარამეტრი თითოეულ ხელსაწყოში, რომელსაც სავარაუდოდ გამოიყენებ.

მისამართის ორი სტილი#

ყოველი S3 მოთხოვნა სამ რამეს ასახელებს: endpoint-ს (რომელი სერვერი), bucket-ს (რომელი კონტეინერი) და key-ს (რომელი ობიექტი). key ყოველთვის გზაში მიდის. კითხვა მხოლოდ ისაა, სად მიდის bucket.

სტილი	მოთხოვნა bucket-ისთვის `media`, key `2026/cat.jpg`	რა სჭირდება
Path-style	`GET https://s3.example.com/media/2026/cat.jpg`	ერთი ჰოსტის სახელი, ერთი სერტიფიკატი
Virtual-hosted	`GET https://media.s3.example.com/2026/cat.jpg`	DNS სახელი და სერტიფიკატი, რომელიც ყველა bucket-ს ფარავს

ქსელში განსხვავება მცირეა. path-style-ში Host header არის endpoint, გზის პირველი სეგმენტი კი bucket. virtual-hosted სტილში Host header bucket-ს ქვედომენად ატარებს, გზა კი key-ით იწყება. ხელმოწერა ორივეს ფარავს, ამიტომ კლიენტს სტილის შუა გზაზე შეცვლა არ შეუძლია: ის მოთხოვნას იმ სტილისთვის აწერს ხელს, რომლითაც მის გაგზავნას აპირებს.

code

# Path-stylePUT /media/2026/cat.jpg HTTP/1.1Host: s3.example.com# Virtual-hosted stylePUT /2026/cat.jpg HTTP/1.1Host: media.s3.example.com

სერვერი, რომელსაც მხოლოდ path-style ესმის, იღებს virtual-hosted მოთხოვნას, ხედავს Host: media.s3.example.com-ს და ან საერთოდ ვერასოდეს იღებს მას (ამ სახელისთვის DNS ჩანაწერი არ არსებობს), ან გზის პირველ სეგმენტს, 2026-ს, bucket-ად აღიქვამს. აქედან მოდის უცნაური "NoSuchBucket: 2026" შეცდომები.

რატომ გადავიდა AWS virtual-hosted-ზე და რატომ არა სხვები#

Path-style S3-ის ორიგინალური URL-ის ფორმატია. Amazon-მა უპირატესობა virtual-hosted სტილს მიანიჭა, რადგან bucket-ის ჰოსტის სახელში ჩასმა DNS-ს საშუალებას აძლევს, თითოეული bucket დამოუკიდებლად მიმართოს: bucket შეიძლება სხვა რეგიონში ან სხვა front-end ფლოტზე ცხოვრობდეს, და კლიენტი, რომელიც media.s3.amazonaws.com-ს ხსნის, სწორ ადგილას ხვდება დამატებითი ნახტომის გარეშე. 2019 წელს AWS-მა გამოაცხადა, რომ ახალი bucket-ებისთვის path-style მოთხოვნები გაუქმდებოდა, შემდეგ კი წინააღმდეგობის გამო ცვლილება განუსაზღვრელი ვადით გადადო. Path-style AWS-ზე კვლავ მუშაობს, მაგრამ AWS-ის ყოველი ახალი ფუნქცია და ყოველი მაგალითი virtual-hosted სტილს ვარაუდობს, რის გამოც SDK-ები მას ნაგულისხმევად იყენებენ.

S3-თავსებადი endpoint-ისთვის, რომელიც ერთი სერვერია, ბალანსი პირიქით არის. virtual-hosted მისამართს სჭირდება:

wildcard DNS ჩანაწერი, *.s3.example.com, რომელიც სერვერზე მიუთითებს, რომ ყოველი bucket-ის სახელი გაიხსნას.
wildcard TLS სერტიფიკატი *.s3.example.com-ისთვის. Let's Encrypt wildcard-ებს მხოლოდ DNS-01 challenge-ით გასცემს, რაც ნიშნავს, რომ გამცემ სისტემას შენს DNS ზონაზე წვდომა უნდა მისცე.
სერვერი, კონფიგურირებული საბაზისო დომენით, რომ იცოდეს, bucket Host header-იდან წაიკითხოს.

Path-style-ს ერთი ჩვეულებრივი A ჩანაწერი და ერთი ჩვეულებრივი სერტიფიკატი სჭირდება. bucket-ების სახელები DNS-ს საერთოდ არ ეხება. სწორედ ამიტომ არის self-hosted ან ერთ-endpoint-იანი საცავისთვის გულწრფელი ნაგულისხმევი path-style, და ამიტომ წერია თითქმის ყველა ასეთი პროდუქტის დოკუმენტაციაში, სადღაც დასაწყისთან ახლოს, "set force path style".

კიდევ ერთი პრაქტიკული მიზეზი არსებობს. bucket-ების სახელებში შეიძლება წერტილები იყოს (backups.example.org დასაშვები სახელია). virtual-hosted სტილში ეს ხდება backups.example.org.s3.example.com, რომელსაც *.s3.example.com-ის wildcard სერტიფიკატი არ ფარავს, რადგან wildcard ზუსტად ერთ label-ს ემთხვევა. path-style-ს ასეთი პრობლემა არ აქვს.

რას აკეთებს რეგიონის სახელი#

S3 კლიენტები რეგიონს ითხოვენ მაშინაც კი, როცა AWS-ს არ ესაუბრები, და ხალხს სამართლიანად აინტერესებს, რა ჩაწერონ.

AWS-ზე რეგიონი ორ საქმეს აკეთებს. ის ირჩევს endpoint-ს (s3.eu-central-1.amazonaws.com) და ის არის Signature Version 4-ის credential scope-ის ნაწილი: ყოველი მოწერილი მოთხოვნა შეიცავს ასეთ სტრიქონს: 20261008/eu-central-1/s3/aws4_request, და სერვერი ხელმოწერას იმ რეგიონით ითვლის ხელახლა, რომელსაც ელოდება. თუ ისინი არ ემთხვევა, AWS პასუხობს AuthorizationHeaderMalformed-ით და გეუბნება, რომელი რეგიონი უნდოდა.

მორგებული endpoint-ის შემთხვევაში პირველი საქმე ქრება - endpoint-ს თავად აწვდი. მეორე რჩება: რეგიონი კვლავ ხელმოწერაშია ჩაშენებული. მთავარია, რომ სერვერმა მიიღოს რეგიონი, რომლითაც კლიენტმა მოაწერა. ზოგი S3-თავსებადი სერვერი ერთი კონკრეტული რეგიონის სახელითაა კონფიგურირებული და ყველაფერ დანარჩენს უარყოფს; სხვები ნებისმიერ მნიშვნელობას იღებენ. როცა საცავი ნებისმიერ რეგიონს იღებს, ჩვეულებრივი არჩევანია us-east-1, რადგან სწორედ მას იყენებს ხელსაწყოების უმეტესობა, როცა არაფერია დაყენებული, და ის აგარიდებს SDK-ის ხარვეზების მთელ კლასს, სადაც ცარიელი რეგიონი შეცდომად ითვლება.

რეგიონი ერთ ადგილასაც ჩნდება, სადაც შეიძლება გიკბინოს: ზოგი SDK, თუ რეგიონი აქვს, endpoint კი არა, მისგან AWS-ის URL-ს აწყობს. თუ ხედავ, რომ შენი კლიენტი s3.us-east-1.amazonaws.com-ს მიმართავს, endpoint-ის პარამეტრი არ აიღო და პრობლემა რეგიონში არ არის.

bucket-ების სახელები და რატომ არსებობს წესები#

S3-ის bucket-ების დასახელების წესები თვითნებური ჩანს, სანამ მათ DNS-ის წესებად არ წაიკითხავ, რაც ისინი სინამდვილეში არიან. რადგან bucket-ს ოდესმე შეიძლება ჰოსტის სახელად მიმართონ, Amazon-ის წესები მოითხოვს სახელებს, რომლებიც სწორი DNS label-ებია:

სიგრძე 3-დან 63 სიმბოლომდე.
მხოლოდ პატარა ასოები, ციფრები, დეფისები და წერტილები.
უნდა იწყებოდეს და მთავრდებოდეს ასოთი ან ციფრით.
არ უნდა ჰგავდეს IP მისამართს (192.168.1.10 დასაშვები bucket-ის სახელი არ არის).
არ შეიძლება ორი წერტილი ერთმანეთის გვერდით, და არც წერტილი დეფისის გვერდით.

S3-თავსებადი სერვერები ჩვეულებრივ იგივე წესებს აიძულებენ მაშინაც, როცა მხოლოდ path-style-ს იყენებენ, რადგან კლიენტები და ხელსაწყოები მათ ვარაუდობენ. დაიცავი პატარა ასოები, ციფრები და დეფისები - game-backups, media-prod, db-dumps-2026 - და ვერასოდეს შეხვდები ხელსაწყოს, რომელიც სახელზე უარს იტყვის. წერტილები საერთოდ გამოტოვე; path-style endpoint-ზე არაფერს მატებენ და ზემოთ აღწერილ სერტიფიკატის პრობლემას იწვევენ, თუ ოდესმე virtual-hosted-ზე გადახვალ.

bucket-ების სახელები ხილულიც არის. ისინი ჩანს ყოველ URL-ში, ყოველ presigned ბმულსა და ლოგის ყოველ ხაზში. ნუ ჩასვამ მასში კლიენტის სახელს, საიდუმლოს ან შიდა პროექტის კოდურ სახელს.

პარამეტრი ყველა გავრცელებულ ხელსაწყოში#

ეს ის ნაწილია, რომელიც სანიშნეში უნდა შეინახო. ქვემოთ თითოეული ხაზი კლიენტს მორგებულ endpoint-თან path-style-ის გამოყენებას აიძულებს.

ხელსაწყო ან SDK	Path-style-ის პარამეტრი	Endpoint-ის პარამეტრი
AWS CLI	`s3 = addressing_style = path` `~/.aws/config`-ში	`--endpoint-url` ან `endpoint_url`
boto3 (Python)	`Config(s3={'addressing_style': 'path'})`	`endpoint_url=`
AWS SDK for JavaScript v3	`forcePathStyle: true`	`endpoint:`
AWS SDK for Go v2	`o.UsePathStyle = true`	`o.BaseEndpoint`
AWS SDK for Java v2	`.forcePathStyle(true)`	`.endpointOverride(URI)`
AWS SDK for PHP / Laravel	`'use_path_style_endpoint' => true`	`'endpoint' =>`
rclone	`force_path_style = true` (ნაგულისხმევი)	`endpoint =`
restic	`-o s3.bucket-lookup=path`	რეპოზიტორიის URL-ში
Cyberduck	"S3 (Deprecated path style requests)" პროფილი	სერვერის ველი
WinSCP	Advanced, Environment, S3, URL style: Path	ჰოსტის ველი

რამდენიმე მათგანი ერთ წინადადებას იმსახურებს.

AWS CLI სტილს თავისი კონფიგურაციის ფაილიდან კითხულობს. ჩადგმული s3 ბლოკი ის ნაწილია, რომელიც ხალხს გამორჩება:

~/.aws/config

[profile store]region = us-east-1endpoint_url = https://s3.example.coms3 =  addressing_style = path

profile-ში ზედა დონის endpoint_url AWS CLI 2.13-იდან არის მხარდაჭერილი; ძველ ვერსიებზე --endpoint-url-ს ყოველ ბრძანებას გადასცემ. S3 საცავის გამოყენება AWS CLI-ით სრულ დაყენებას შეიცავს.

boto3-ში სტილი botocore.config.Config ობიექტში ცხოვრობს:

python

import boto3from botocore.config import Configs3 = boto3.client(    "s3",    endpoint_url="https://s3.example.com",    region_name="us-east-1",    aws_access_key_id="AKIA...",    aws_secret_access_key="...",    config=Config(s3={"addressing_style": "path"}, signature_version="s3v4"),)

JavaScript SDK v3-ში forcePathStyle კლიენტის კონსტრუქტორზე ზის:

javascript

import { S3Client } from "@aws-sdk/client-s3";const s3 = new S3Client({  endpoint: "https://s3.example.com",  region: "us-east-1",  forcePathStyle: true,  credentials: { accessKeyId: "AKIA...", secretAccessKey: "..." },});

Laravel PHP SDK-ის ოფციას თავისი filesystem-ის კონფიგით ავლენს, რომელსაც ჩვეულებრივ .env-ში AWS_USE_PATH_STYLE_ENDPOINT=true მართავს. rclone S3 remote-ებისთვის force_path_style-ს უკვე ნაგულისხმევად true-ზე აყენებს, რაც ერთ-ერთი მიზეზია, რის გამოც ის უცნაურ endpoint-ებთან პირველივე ცდაზე მუშაობს. restic-ის ნაგულისხმევია auto, რაც ნიშნავს virtual-hosted-ს Amazon-ისა და Google-ის endpoint-ებისთვის და path-style-ს ყველაფერი დანარჩენისთვის, ამიტომ მასაც ჩვეულებრივ ფლაგი არ სჭირდება; ოფცია არსებობს იმ შემთხვევისთვის, როცა ავტომატური ამოცნობა ცდება. ორივე SDK-ის კოდის მაგალითები, ატვირთვისა და ჩამოთვლის ჩათვლით, არის სტატიაში S3 Node.js-იდან და Python-იდან.

როგორ გამოიყურება არასწორი სტილი#

სიმპტომები თვალშისაცემია, როცა ერთხელ ნახავ.

სიმპტომი	სავარაუდო მიზეზი
`Could not connect to the endpoint URL: https://media.s3.example.com/`	Virtual-hosted სტილი, bucket-ის ქვედომენისთვის DNS არ არის
`getaddrinfo ENOTFOUND media.s3.example.com`	იგივე, Node-იდან
სერტიფიკატის შეცდომა, რომელიც `media.s3.example.com`-ს ასახელებს	Virtual-hosted სტილი; სერტიფიკატი მხოლოდ `s3.example.com`-ს ფარავს
`NoSuchBucket`, რომელიც შენი key-ის პირველ საქაღალდეს ასახელებს	სერვერმა გზა წაიკითხა როგორც bucket/key; კლიენტმა virtual-hosted გაგზავნა
Cyberduck: "Cannot read container configuration"	ნაგულისხმევი S3 პროფილი მხოლოდ path-style სერვერთან
`SignatureDoesNotMatch` მხოლოდ სტილის შეცვლის შემდეგ	proxy-მ `Host` გადაწერა, ან კლიენტმა ძველი სტილი cache-ში შეინახა

პირველი ორი ყველაზე გავრცელებული და ყველაზე ადვილად ამოსაცნობია: შეხედე ჰოსტის სახელს შეცდომაში. თუ ის შენი bucket-ის სახელით იწყება, კლიენტი virtual-hosted სტილს იყენებს და ზემოთ ცხრილიდან პარამეტრი სჭირდება.

ბოლო უფრო ფაქიზია. ხელმოწერა Host header-ს ფარავს. თუ საცავის წინ მდგომი reverse proxy მოთხოვნებს იმისგან განსხვავებული Host-ით გადასცემს, რაც კლიენტმა გამოიყენა, ყოველი ხელმოწერა მარცხდება, მიუხედავად იმისა, რომ ავტორიზაციის მონაცემები სწორია. S3 endpoint-ის წინ მდგომმა proxy-მ ორიგინალი Host უცვლელად უნდა გაატაროს.

ერთ შეცდომას ხშირად მისამართის სტილს აბრალებენ, თუმცა მასთან კავშირი არ აქვს. 2025 წლის დასაწყისიდან AWS CLI (2.23-იდან) და მიმდინარე AWS SDK-ები ატვირთვებს ნაგულისხმევად CRC-ზე დაფუძნებულ მთლიანობის checksum-ებს უმატებენ. ზოგი S3-თავსებადი სერვერი მათ არ იღებს, და შეცდომა ჩნდება როგორც SignatureDoesNotMatch, MissingContentLength ან checksum-ის საჩივარი PutObject-ზე, მაშინ როცა ჩამოთვლა და ჩამოტვირთვა კარგად მუშაობს. გამოსწორება ორი პარამეტრია, რომლებიც კლიენტს checksum-ებს მხოლოდ მაშინ აგზავნინებს, როცა ოპერაცია მათ მოითხოვს: request_checksum_calculation = when_required და response_checksum_validation = when_required AWS-ის კონფიგის profile-ში, ან ეკვივალენტური ოფციები SDK-ში. თუ ატვირთვა მარცხდება და წაკითხვა გამოდის, ეს ყველაფერზე ადრე სცადე.

Path-style, HTTPS და შენი საკუთარი დომენი#

path-style endpoint მხოლოდ ერთი ჰოსტის სახელია, ამიტომ მის წინ HTTPS-ის დაყენება იგივე საქმეა, რაც ნებისმიერი ვებ სერვისისთვის: A ჩანაწერი, რომელიც proxy-ზე მიუთითებს, სერტიფიკატი ამ სახელისთვის და proxy, რომელიც საცავის plain-HTTP პორტზე გადაამისამართებს. რას აკეთებს reverse proxy მექანიკას განიხილავს, ხოლო შენი დომენი და მისი სერტიფიკატი - DNS-ის მხარეს.

სწორედ ასეა აგებული RE:NODE-ის S3 საცავი. endpoint საკუთარ პორტზე უბრალო HTTP-ით პასუხობს, და ყოველ გეგმას აქვს proxy სლოტი: მიმართე ჰოსტის სახელი, მაგალითად s3.example.com, ნაჩვენებ მისამართზე, და სერტიფიკატი შენთვის გაიცემა და განახლდება. კლიენტები შემდეგ იყენებენ https://s3.example.com-ს path-style მისამართით და ნებისმიერი რეგიონის სახელით. პირდაპირ პორტზე უბრალო HTTP ტესტირებისთვის მუშაობს, მაგრამ მოთხოვნის body-ები დაუშიფრავად მოგზაურობს, ამიტომ ყველაფერი, რაც შენი საკუთარი მანქანიდან გადის, HTTPS სახელით უნდა წავიდეს.

path-style მოთხოვნა proxy სლოტის გავლით

რადგან bucket ჰოსტის სახელში არასოდეს ჩნდება, ერთი სერტიფიკატი ფარავს ყველა bucket-ს, რომელსაც ოდესმე შექმნი, და ახლის დამატებისას DNS-ში არაფრის შეცვლა არ არის საჭირო.

Presigned URL-ები და საჯარო ბმულები#

მისამართის სტილი ასევე განსაზღვრავს URL-ებს, რომლებსაც სხვა ადამიანებს აძლევ. path-style კლიენტის მიერ დაგენერირებული presigned URL ასე გამოიყურება: https://s3.example.com/media/2026/cat.jpg?X-Amz-Algorithm=...&X-Amz-Signature=..., და ჰოსტის სახელი იმის ნაწილია, რაც მოიწერა. აქედან ორი შედეგი გამომდინარეობს:

presigned URL-ები დააგენერირე იმავე endpoint-ით, რომელსაც ბრაუზერი გამოიყენებს. URL, რომელიც http://203.0.113.10:PORT-ისთვის მოიწერა და შემდეგ ხელით https://s3.example.com-ზე გადაიწერა, ხელმოწერის შემოწმებას ვერ გადის.
თუ მოგვიანებით path-style-იდან virtual-hosted-ზე (ან სხვა პროვაიდერზე) გადახვალ, ძველი presigned URL-ები მუშაობას წყვეტს. მათ ისედაც ვადა გასდით, მაგრამ ელფოსტაში არსებული ხანგრძლივი ბმულები გაფუჭდება.

Presigned URL-ები ატვირთვისა და ჩამოტვირთვისთვის განიხილავს ვადას, PUT ატვირთვებს ბრაუზერიდან და CORS-ს.

სტილის არჩევა საკუთარი კოდისთვის#

თუ წერ კოდს, რომელიც S3-ს ესაუბრება, endpoint და სტილი კონფიგურაციად აქციე და არა მუდმივებად. პარამეტრების პატარა ბლოკი S3_ENDPOINT, S3_REGION, S3_BUCKET და S3_FORCE_PATH_STYLE-ით იმავე კოდს საშუალებას აძლევს, ერთ გარემოში AWS-თან იმუშაოს, მეორეში კი self-hosted საცავთან, და პროვაიდერის შეცვლას ოთხი ცვლადის ცვლილებად აქცევს. გარემოს ცვლადები და საიდუმლოები ამ ნიმუშს შეიცავს.

.env

S3_ENDPOINT=https://s3.example.comS3_REGION=us-east-1S3_BUCKET=mediaS3_FORCE_PATH_STYLE=trueS3_ACCESS_KEY_ID=AKIA...S3_SECRET_ACCESS_KEY=...

სანამ ახალ endpoint-ს აპლიკაციაში ჩართავ, ბრძანების ხაზიდან დაამტკიცე, რომ მუშაობს. სამი ბრძანება ერთდროულად პასუხობს ყველა კითხვას სტილზე, რეგიონსა და ავტორიზაციის მონაცემებზე:

bash

$ aws s3 ls --profile store$ aws s3 cp ./test.txt s3://media/test.txt --profile store$ aws s3 ls s3://media/ --profile store --debug 2>&1 | grep -i "host"

პირველი bucket-ებს ჩამოთვლის, რაც endpoint-სა და გასაღებებს ამტკიცებს. მეორე ობიექტს წერს, რაც body-იანი მოთხოვნის ხელმოწერას ამტკიცებს. მესამე მოთხოვნის დეტალებს ბეჭდავს; Host ხაზი გეუბნება, რომელი სტილი გამოიყენა კლიენტმა სინამდვილეში, რაც კონფიგის ცვლილების ამოქმედების დადასტურების ყველაზე სწრაფი გზაა. თუ სამივე CLI-ში მუშაობს, შენი აპლიკაცია კი მაინც მარცხდება, აპლიკაციის SDK იგივე პარამეტრებს არ იღებს.

არა-AWS endpoint-ზე virtual-hosted სტილის უპირატესობის მინიჭების მიზეზი იშვიათად არსებობს, თუ პროვაიდერი ამას არ მოითხოვს. Path-style უფრო მარტივად დგება TLS-ის უკან, უძლებს წერტილებიან bucket-ების სახელებს და მას ყველა S3-თავსებადი კლიენტი უჭერს მხარს. თავად AWS-ზე SDK-ის ნაგულისხმევი ხელუხლებლად დატოვე.

FAQ#

path-style მოძველებულია?

AWS-ზე მისი გამოყენება არ არის რეკომენდებული და ოდესღაც მისი მოხსნაც იყო დაგეგმილი, მაგრამ მოხსნა გადაიდო და path-style მოთხოვნები კვლავ მუშაობს. S3-თავსებად endpoint-ებზე ეს ჩვეულებრივი, მხარდაჭერილი რეჟიმია. სიტყვა "deprecated" ზოგიერთი ხელსაწყოს მენიუში AWS-ის პოზიციას ეხება და არა პროტოკოლს.

რომელი რეგიონი გამოვიყენო S3-თავსებადი საცავისთვის?

ის, რასაც პროვაიდერი გეუბნება. თუ ის ნებისმიერ სახელს იღებს, გამოიყენე us-east-1, რასაც ხელსაწყოების უმეტესობა ვარაუდობს და რაც SDK-ს ყველაზე ნაკლებად შეაფერხებს. რეგიონი მხოლოდ კლიენტსა და სერვერს შორის უნდა იყოს თანმიმდევრული.

შემიძლია IP მისამართი გამოვიყენო endpoint-ად?

კი, მხოლოდ path-style-ით. virtual-hosted მოთხოვნას დასჭირდებოდა ჰოსტის სახელი, როგორიცაა bucket.203.0.113.10, რაც სწორი სახელი არ არის. ლოკალური ტესტირების მიღმა ყველაფრისთვის გამოიყენე ჰოსტის სახელი HTTPS-ით, რომ ტრაფიკი დაშიფრული იყოს.

რატომ მუშაობს იგივე გასაღები rclone-ში და არა ჩემს აპლიკაციაში?

rclone ნაგულისხმევად path-style-ს იყენებს, SDK-ების უმეტესობა კი virtual-hosted-ს. თუ ავტორიზაციის მონაცემები და endpoint იდენტურია, განსხვავება თითქმის ყოველთვის მისამართის სტილშია. დააყენე path-style-ის ოფცია SDK-ში.

მოქმედებს მისამართის სტილი სისწრაფეზე?

ერთ-endpoint-იან საცავზე არა. ორივე სტილი ერთსა და იმავე სერვერს აღწევს; ერთადერთი განსხვავება ისაა, რომელი header ატარებს bucket-ის სახელს. AWS-ზე virtual-hosted სტილს შეუძლია უფრო პირდაპირ მიმართოს, რაც ნაწილობრივ ხსნის, რატომ ამჯობინებს მას Amazon.

კომენტარები

სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.