雖然經常用於不同的目的,但索引文檔最初的目的是從概念上來說是每個文件夾中所有文件的「索引」(目錄列表或其他內容摘要),所以這個配置參數指定索引文檔爲整個存儲桶中的每個文件夾返回,如果這樣的文檔存在於文件夾 ......這對於整個存儲桶來說不是一個單獨的配置「事物」。
如果您嘗試配置已經被S3所接受,這將有以下影響,假設「example.com」水桶名稱:
browser address bar file (object) actually returned
--------------------------- ------------------------------------
http://example.com example.com/test/index.html
http://example.com/help example.com/help/test/index.html
http://example.com/foo/test example.com/foo/test/test/index.html
這似乎不太可能,這是你真正意。
但是,索引文件的工作原理是......它們在概念上旨在與目錄層次結構中每一層的其他內容相關聯,這當然可以是文件的實際列表,或者可以是「索引」中的任何「頁面」的範圍要廣泛和模糊一般,例如您希望訪問者在訪問您網站上的特定「目錄」時看到的着陸頁,這當然是在現代網絡通常不是概念化爲「目錄」,而是簡單地稱爲「頁面」。
因此,索引文檔必須立即在相同的/
定界符下,並且在其自己的規範中不能包含額外的/
。
example.com的索引文件必須存儲在example.com/index.html(假設「index.html」是您選擇的索引文件名) - 它必須存儲在「目錄」中索引,就像在傳統的Web服務器上一樣,在某些配置中,Web服務器將實際顯示文件的目錄列表,「索引」頁面在「索引」頁面實際存在的情況下替換該目錄列表。當然,S3沒有默認的目錄列表頁面功能。
http://docs.aws.amazon.com/AmazonS3/latest/dev/IndexDocumentSupport.html
與此相反的索引文件,錯誤文件,如果你配置它,就是無論在哪裏,鬥內,404發生時使用的全局配置,所以斜線在支持條目。 AWS控制檯提示對於兩個條目的性質提示很明顯,它們的行爲如此不同以至於它們在視覺上應該更加分離。
你會注意到,「子鬥」不是實際來看,對你所描述的,這與它的鍵(路徑),這給被嵌套在外觀分隔符對象在一個目錄或文件夾下。
爲清楚起見,我用的詞「文件夾」和「目錄」很隨意地遍佈所有這個答案,與傳統意義......但是對於技術的準確性,我會提的是S3的對象是不是真的在內部存儲以分層的方式「在目錄中」。它以這種方式出現,並且出於實際的目的,它是這樣工作的;然而,實際上,/
字符雖然接近於對象密鑰中的另一個字符,但由於其常規用作目錄分隔符而得到了一些特殊處理,但它不同於一些更傳統的文件系統。由於S3的S3 internally hashes the key(「路徑」)是不存在的,因此不需要像傳統文件系統中需要的那樣管理與每個目錄中的「文件在一起」每個對象用於其內部存儲分區邏輯。
我爲什麼要索引文件指向我的'test_folder/index.html'怎麼把我的桶裏面我有其他的'folders'的原因。而且當我訪問我的瀏覽器'http:// mybucket/test_folder'給了我一個'訪問被拒絕的問題' – user2720708
這似乎是一個非常囉嗦的答案,說「把你的index.html放在根目錄下」。 –
然後,您可能需要再次閱讀它,因爲這不是它所說的。索引文檔名稱是*名稱*,而不是*路徑*。把它們放在你需要它們的地方,但要明白,與錯誤文檔不同,它們是合格/解決上下文的。 –