就HTTP而言，客戶端下載的只是一堆字節(jié)。 但是，客戶真的很想知道如何解釋這些字節(jié)。 它是圖像嗎？ 或者也許是ZIP文件？ 本系列的最后一部分描述了如何向客戶端提示她下載的內(nèi)容。

設(shè)置

內(nèi)容類型描述了要返回的資源的MIME類型 。 此標(biāo)頭指示W(wǎng)eb瀏覽器如何處理從下載服務(wù)器流出的字節(jié)流。 如果沒有此標(biāo)頭，瀏覽器將無法得知其實際接收到的內(nèi)容，只會像顯示文本文件一樣顯示內(nèi)容。 不用說二進(jìn)制PDF（請參見上面的屏幕截圖），像文本文件一樣顯示的圖像或視頻看起來并不好。 最難的部分是以某種方式實際獲得媒體類型。 幸運的是，Java本身有一個用于根據(jù)資源的擴(kuò)展名和/或內(nèi)容來猜測媒體類型的工具：

import com.google.common.net.MediaType; import java.io.*; import java.time.Instant;public class FileSystemPointer implements FilePointer {private final MediaType mediaTypeOrNull;public FileSystemPointer(File target) {final String contentType = java.nio.file.Files.probeContentType(target.toPath());this.mediaTypeOrNull = contentType != null ?MediaType.parse(contentType) :null;}

請注意，使用Optional<T>作為類字段不是慣用的，因為它不是可Serializable并且我們避免了潛在的問題。 知道媒體類型后，我們必須在響應(yīng)中返回它。 注意，這一小段代碼使用了JDK 8和Guava中的Optional ，以及Spring框架和Guava中的MediaType類。 多么糟糕的類型系統(tǒng)！

private ResponseEntity<Resource> response(FilePointer filePointer, HttpStatus status, Resource body) {final ResponseEntity.BodyBuilder responseBuilder = ResponseEntity.status(status).eTag(filePointer.getEtag()).contentLength(filePointer.getSize()).lastModified(filePointer.getLastModified().toEpochMilli());filePointer.getMediaType().map(this::toMediaType).ifPresent(responseBuilder::contentType);return responseBuilder.body(body); }private MediaType toMediaType(com.google.common.net.MediaType input) {return input.charset().transform(c -> new MediaType(input.type(), input.subtype(), c)).or(new MediaType(input.type(), input.subtype())); }@Override public Optional<MediaType> getMediaType() {return Optional.ofNullable(mediaTypeOrNull); }

保留原始文件名和擴(kuò)展名

當(dāng)您直接在Web瀏覽器中打開文檔時，雖然Content-type效果很好，但是可以想象您的用戶將該文檔存儲在磁盤上。 瀏覽器是決定顯示還是存儲下載的文件不在本文的討論范圍之內(nèi)，但是我們應(yīng)該為兩者做好準(zhǔn)備。 如果瀏覽器只是將文件存儲在磁盤上，則必須使用某種名稱進(jìn)行保存。 默認(rèn)情況下，Firefox將使用URL的最后一部分，在本例中，該部分恰好是資源的UUID。 不太用戶友好。 鉻是好一點-知道根據(jù)MIME類型Content-type報頭，將試探性地加入適當(dāng)?shù)臄U(kuò)展名，例如.zip中的情況下， application/zip 。 但是文件名仍然是隨機(jī)的UUID，而用戶上傳的文件可能是cats.zip 。 因此，如果您的目標(biāo)是瀏覽器而不是自動化客戶端，則最好使用真實名稱作為URL的最后一部分。 我們?nèi)匀幌Ｍ褂肬UID在內(nèi)部區(qū)分資源，避免沖突并且不公開我們的內(nèi)部存儲結(jié)構(gòu)。 但是在外部，我們可以重定向到用戶友好的URL，但為了安全起見保留UUID。 首先，我們需要一個額外的端點：

@RequestMapping(method = {GET, HEAD}, value = "/{uuid}") public ResponseEntity<Resource> redirect(HttpMethod method,@PathVariable UUID uuid,@RequestHeader(IF_NONE_MATCH) Optional<String> requestEtagOpt,@RequestHeader(IF_MODIFIED_SINCE) Optional<Date> ifModifiedSinceOpt) {return findExistingFile(method, uuid).map(file -> file.redirect(requestEtagOpt, ifModifiedSinceOpt)).orElseGet(() -> new ResponseEntity<>(NOT_FOUND)); }@RequestMapping(method = {GET, HEAD}, value = "/{uuid}/{filename}") public ResponseEntity<Resource> download(HttpMethod method,@PathVariable UUID uuid,@RequestHeader(IF_NONE_MATCH) Optional<String> requestEtagOpt,@RequestHeader(IF_MODIFIED_SINCE) Optional<Date> ifModifiedSinceOpt) {return findExistingFile(method, uuid).map(file -> file.handle(requestEtagOpt, ifModifiedSinceOpt)).orElseGet(() -> new ResponseEntity<>(NOT_FOUND)); }private Optional<ExistingFile> findExistingFile(HttpMethod method, @PathVariable UUID uuid) {return storage.findFile(uuid).map(pointer -> new ExistingFile(method, pointer, uuid)); }

如果仔細(xì)觀察，甚至沒有使用{filename} ，它只是瀏覽器的提示。 如果需要額外的安全性，可以將提供的文件名與映射到給定UUID文件名進(jìn)行比較。 這里真正重要的是，僅要求提供UUID重定向我們：

$ curl -v localhost:8080/download/4a8883b6-ead6-4b9e-8979-85f9846cab4b > GET /download/4a8883b6-ead6-4b9e-8979-85f9846cab4b HTTP/1.1 ... < HTTP/1.1 301 Moved Permanently < Location: /download/4a8883b6-ead6-4b9e-8979-85f9846cab4b/cats.zip

而且您需要進(jìn)行一次額外的網(wǎng)絡(luò)行程來獲取實際文件：

> GET /download/4a8883b6-ead6-4b9e-8979-85f9846cab4b/cats.zip HTTP/1.1 ... > HTTP/1.1 200 OK < ETag: "be20c3b1...fb1a4" < Last-Modified: Thu, 21 Aug 2014 22:44:37 GMT < Content-Type: application/zip;charset=UTF-8 < Content-Length: 489455

該實現(xiàn)很簡單，但是為了避免重復(fù)，對其進(jìn)行了一些重構(gòu)：

public ResponseEntity<Resource> redirect(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt) {if (cached(requestEtagOpt, ifModifiedSinceOpt))return notModified(filePointer);return redirectDownload(filePointer); }public ResponseEntity<Resource> handle(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt) {if (cached(requestEtagOpt, ifModifiedSinceOpt))return notModified(filePointer);return serveDownload(filePointer); }private boolean cached(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt) {final boolean matchingEtag = requestEtagOpt.map(filePointer::matchesEtag).orElse(false);final boolean notModifiedSince = ifModifiedSinceOpt.map(Date::toInstant).map(filePointer::modifiedAfter).orElse(false);return matchingEtag || notModifiedSince; }private ResponseEntity<Resource> redirectDownload(FilePointer filePointer) {try {log.trace("Redirecting {} '{}'", method, filePointer);return ResponseEntity.status(MOVED_PERMANENTLY).location(new URI("/download/" + uuid + "/" + filePointer.getOriginalName())).body(null);} catch (URISyntaxException e) {throw new IllegalArgumentException(e);} }private ResponseEntity<Resource> serveDownload(FilePointer filePointer) {log.debug("Serving {} '{}'", method, filePointer);final InputStreamResource resource = resourceToReturn(filePointer);return response(filePointer, OK, resource); }

您甚至可以進(jìn)一步使用高階函數(shù)來避免重復(fù)：

public ResponseEntity<Resource> redirect(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt) {return serveWithCaching(requestEtagOpt, ifModifiedSinceOpt, this::redirectDownload); }public ResponseEntity<Resource> handle(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt) {return serveWithCaching(requestEtagOpt, ifModifiedSinceOpt, this::serveDownload); }private ResponseEntity<Resource> serveWithCaching(Optional<String> requestEtagOpt, Optional<Date> ifModifiedSinceOpt, Function<FilePointer, ResponseEntity<Resource>> notCachedResponse) {if (cached(requestEtagOpt, ifModifiedSinceOpt))return notModified(filePointer);return notCachedResponse.apply(filePointer); }

顯然，額外的重定向是每次下載都必須支付的額外費用，因此這是一個折衷方案。 您可以考慮基于User-agent啟發(fā)式（如果是瀏覽器，則為重定向；如果是自動客戶端，則為服務(wù)器），以避免非人工客戶端的重定向。 這樣就結(jié)束了我們有關(guān)文件下載的系列文章。 HTTP / 2的出現(xiàn)必將帶來更多的改進(jìn)和技術(shù)，例如確定優(yōu)先級。

編寫下載服務(wù)器

• 第一部分：始終流式傳輸，永遠(yuǎn)不要完全保留在內(nèi)存中
• 第二部分：標(biāo)頭：Last-Modified，ETag和If-None-Match
• 第三部分：標(biāo)頭：內(nèi)容長度和范圍
• 第四部分：有效地實現(xiàn)HEAD操作
• 第五部分：油門下載速度
• 第六部分：描述您發(fā)送的內(nèi)容（內(nèi)容類型等）

• 這些文章中開發(fā)的示例應(yīng)用程序可在GitHub上找到。

翻譯自: https://www.javacodegeeks.com/2015/07/writing-a-download-server-part-vi-describe-what-you-send-content-type-et-al.html

總結(jié)

以上是生活随笔為你收集整理的编写下载服务器。 第六部分：描述您发送的内容（内容类型等）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。