如何做网站地图,做网站常用图标,电商运营平台有哪些,常州营销推广公司502无法解析服务器标头这次#xff0c;我们将探索更多HTTP请求和响应标头#xff0c;以改善下载服务器的实现#xff1a; Content-length和Range 。 前者表示下载量很大#xff0c;后者允许部分下载文件#xff0c;或者从我们开始的地方失败后继续下载。 Content-length响… 502无法解析服务器标头 这次我们将探索更多HTTP请求和响应标头以改善下载服务器的实现 Content-length和Range 。 前者表示下载量很大后者允许部分下载文件或者从我们开始的地方失败后继续下载。 Content-length响应标头对于跟踪下载进度的客户端非常有用。 如果在甚至开始流传输字节之前就提前发送了预期的资源大小则Web浏览器之类的客户端可以显示非常准确的进度条甚至可以通过测量平均下载速度来估计总下载时间。 如果没有Content-length客户端则客户端将仅保持尽可能长的下载时间希望流结束一天。 但是在某些情况下很难获得准确的内容长度。 例如也许您从其他下载服务器流式传输资源或者您的资源被即时压缩并直接发送到Servlet响应。 在这两种情况下您能做的最好的事情就是实际上在磁盘上本地缓存数据弄清楚大小是多少并在数据可用时开始流式传输。 这与始终流式传输永远不要完全保留在内存中的建议并不矛盾。 在这种情况下我们将临时文件存储在磁盘上但是在完全准备好并且知道其大小后仍将流式传输。 从Java的角度来看提供内容长度非常简单 private ResponseEntityResource response(FilePointer filePointer, HttpStatus status, Resource body) {return ResponseEntity.status(status).eTag(filePointer.getEtag()).contentLength(filePointer.getSize()).lastModified(filePointer.getLastModified().toEpochMilli()).body(body);
} 请注意还存在一个Resource.contentLength()方法但是不同类型的资源对它的计算方式有所不同有时会急于读取整个资源。 我有自己的FilePointer抽象知道我们要下载的文件大小。 Range标头是RFC 7233中很好描述的HTTP / 1.1的“新”功能。 这个想法是客户端可以仅请求一部分资源就字节范围而言主要有两个原因 先前的下载已中断我们不想重复相同的工作。 在这种情况下客户端知道收到了多少字节并要求剩余部分 我们正在流式传输数据例如视频我们想跳过某些部分。 考虑一下像Youtube这样的在线播放器然后单击进度条中间的。 客户可以简单地估计它现在需要文件的哪一部分与电影持续时间成比例。 并非所有服务器都需要实现Range请求因此需要进行一些协商。 第一个客户端发送一个请求仅请求文件的一部分在此示例中为前100个字节 GET /big_buck_bunny_1080p_surround.avi HTTP/1.1Range: bytes0-99
... 如果目标服务器支持范围请求则响应206 Partial Content HTTP/1.1 206 Partial ContentLast-Modified: Tue, 06 May 2008 11:21:35 GMTETag: 8000089-375a6422-44c8e0d0f0dc0Accept-Ranges: bytesContent-Length: 100Content-Range: bytes 0-99/928670754 这里有很多有趣的标题。 首先是206而不是通常的200 OK。 如果为200 OK则客户端必须假定服务器不支持范围请求。 示例服务器的运行情况非常好它还会向我们发送Last-Modified和ETag标头以改善缓存。 此外服务器通过发送Accept-Ranges标头确认其能够处理Range请求。 当前仅广泛使用bytes 但是RFC将来允许其他范围单位秒帧最后两个标头是最有趣的。 Content-Length不再声明资源的总大小而是我们请求的范围的大小在这种情况下为100字节。 完整资源的大小以Content-Range编码 bytes 0-99/928670754 。 就我们收到的内容而言服务器非常精确前100个字节 0-99 而总资源大小为928670754 。 知道客户端的总大小后基本上可以请求多个文件中的文件部分。 Range请求的规范具有很大的灵活性例如我们可以在一个请求中请求多个范围例如 GET /big_buck_bunny_1080p_surround.avi HTTP/1.1Range: bytes0-9,1000-1009
...HTTP/1.1 206 Partial ContentAccept-Ranges: bytesContent-Type: multipart/byteranges; boundary5187ab27335732
--5187ab27335732
Content-type: video/x-msvideo
Content-range: bytes 0-9/928670754[data]
--5187ab27335732
Content-type: video/x-msvideo
Content-range: bytes 1000-1009/928670754[data]
--5187ab27335732-- 但是服务器可以自由地优化多个范围请求例如重新布置它们合并等。从头开始实现部分请求超出了本文的范围我希望您不必自己做。 例如从4.2.x开始的Spring对静态资源的部分请求具有全面的内置支持请参阅 ResourceHttpRequestHandler第463行 。 编写下载服务器 第一部分始终流式传输永远不要完全保留在内存中 第二部分标头Last-ModifiedETag和If-None-Match 第三部分标头内容长度和范围 第四部分有效地执行HEAD操作 第五部分油门下载速度 第六部分描述您发送的内容内容类型等 这些文章中开发的示例应用程序可在GitHub上找到。 翻译自: https://www.javacodegeeks.com/2015/07/writing-a-download-server-part-iii-headers-content-length-and-range.html502无法解析服务器标头
