webdav

问题 最近电信把我的公网地址收回去了，之前做好的网络端口映射失效了，在公司已经不能愉快地访问家里的网络。原先网络结构示意图如下： (直接访问方案网络结构图) 只需要对电信光猫(也是个路由器)和家用路由器进行端口映射的配置即可，而针对地址是“动态”的这个问题，只需要弄个动态域名解释即可。而现在变成这样： (无公网地址的直接访问方案网络结构图) 电信光猫不具备真正的公网地址了。如何查看自己的光猫是否有公网IP地址？不难，登录到光猫去，看网络状态，会看到它的IP地址： (电信光猫上的地址查询) 然后上www.ip138.com，就能看到自己现在暴露在公网上的IP地址： 看看光猫上的地址和这里显示的地址是否相同，如果相同，那光猫就有公网地址，否则就没有。 回到问题中来，现在电信的路由器不可能给我做端口映射的，那咋弄？ 这就是所谓的“内网穿透”技术了。 群晖的方案 就是quickconnect.to了，原理就是NAS主动连接群晖的服务器，而quickconnect.to也是指向群晖的服务器的，群晖再将请求转到NAS去，同事负责将从NAS回复的结果转回给用户。说白了，这个具有公网地址的群晖就起到了一个中介的作用。 (群晖方案网络结构图) 群晖的方案自然是非常简易的，用户甚至都不用了解怎么连接这些细节，只需要注册好账号密码，傻瓜式地打开quickconnect.to即可。 但弊端也很明显

HTTP 响应状态代码指示特定 HTTP 请求是否已成功完成。响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)。状态代码由 section 10 of RFC 2616定义 信息响应 100 Continue 这个临时响应表明，迄今为止的所有内容都是可行的，客户端应该继续请求，如果已经完成，则忽略它。 101 Switching Protocol 该代码是响应客户端的 Upgrade 标头发送的，并且指示服务器也正在切换的协议。 102 Processing (WebDAV) 此代码表示服务器已收到并正在处理该请求，但没有响应可用。 103 Early Hints 此状态代码主要用于与Link 链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源。 成功响应 200 OK 请求成功。成功的含义取决于HTTP方法： GET：资源已被提取并在消息正文中传输。 HEAD：实体标头位于消息正文中。 POST：描述动作结果的资源在消息体中传输。 TRACE：消息正文包含服务器收到的请求消息 201 Created 该请求已成功，并因此创建了一个新的资源。这通常是在POST请求，或是某些PUT请求之后返回的响应。 202 Accepted 请求已经接收到，但还未响应

漏洞名称 Microsoft IIS WebDAV ScStoragePathFromUrl函数缓冲区溢出漏洞(CVE-2017-7269) 漏洞描述 Windows Server是微软发布的一系列服务器操作系统。Internet Information Services（IIS）是一套运行于Microsoft Windows中的互联网基本服务。 Microsoft Windows Server 2003 R2中的IIS 6.0版本中的WebDAV服务的‘ScStoragePathFromUrl’函数存在缓冲区溢出漏洞。远程攻击者可通过发送特制的PROPFIND请求利用该漏洞执行任意代码。 <*来源：Zhiniang Peng & Chen Wu 链接：https://github.com/edwardz246003/IIS_exploit *> 解决方法 临时解决方案： 2015年7月15日，微软已停止对Windows Server 2003的支持，所以官方没有相关解决方案，建议用户升级到最新系统 Windows Server 2016 暂时无法升级的客户可采用以下方法防护此漏洞 1. 关闭IIS下的WebDAV服务 2. 若直接关闭WebDAV会对您的业务造成影响，可针对WebDAV开放的方法进行灵活配置，如禁用PROPFIND方法： 1)

按虚拟器上搭建webdav服务器方法搭建完WebDav服务器之后，编程实现获取webdav服务器文件目录结构时发现使用PROPFIND方法请求时，发生403错误，被服务器拒绝。查找资料发现webdav配置没有对propfind开放。重新如下设置得以解决 需要在IIS中WebDav创作规 则修改WebDav设置 来源： CSDN 作者： kingwebo'sZone 链接： https://blog.csdn.net/weixin_40029679/article/details/104616324

说到想写这篇博客 这几天来，因为疫情在家 闲来无事在网上了解了了几款开源私有网盘的应用，比如nextcloud和seafile 在实际部署的过程中发现nextcloud虽然界面美观，但是整体是由php开发的，而且文档还是英文，不对我胃口（我在网上找开源网盘也是想自己动手开发出一需要云存储数据的应用，不过本人以vue+spring开发为主，php啃不动撒） 对比nextcloud，seafile是由国人团队开发，还提供相对nextcloud更为全面的API接口。 seafile API文档地址 说回重点 小生在seafile的文档中看到了两个比较陌生的词WebDAV和FUSE，后者是一种虚拟的文件系统技术，可以在文件系统上挂载一个虚拟目录。如果结合一些Web API可实现 将云服务器磁盘(或者说网盘应用)挂载到本地 ，嘿嘿，就我而言很方便我挂载数据到多个服务器上，运行一些不方便拓展的工具，如fsl，FreeSurfer，MATLAB等，不用反复下载删除，这可是极好的。 但就如何开发而言，很遗憾小生了解不多，但找到了别人代码直接用，代码也比较简洁便于学习，在此上 Github 。 这次是真的重点 关于WebDAV这个名词，我百度后给出的答案要么是啥啥啥基于WebDAV的服务广告啊，要么是这个解释 百度百科 WebDAV （Web-based Distributed Authoring

请求网页总会返回一些奇奇怪怪的状态码，把这个整出来，方便查阅 文章目录 1xx（临时响应） 2xx（成功） 3xx（已重定向） 4xx（请求错误） 5xx（服务器错误） 数据来源1 数据来源2 1xx（临时响应） 用于表示临时响应并需要请求者执行操作才能继续的状态代码。 代码 说明 100 （继续） 请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。 101 （切换协议） 请求者已要求服务器切换协议，服务器已确认并准备进行切换。 102 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 2xx（成功） 用于表示服务器已成功处理了请求的状态代码。 代码 说明 200 （成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果您的 robots.txt 文件显示为此状态，那么，这表示 Googlebot 已成功检索到该文件。 201 （已创建） 请求成功且服务器已创建了新的资源。 202 （已接受） 服务器已接受了请求，但尚未对其进行处理。 203 （非授权信息） 服务器已成功处理了请求，但返回了可能来自另一来源的信息。 204 （无内容） 服务器成功处理了请求，但未返回任何内容。 205 （重置内容） 服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图