Web | W10N

HTML5 中 div section article 的区别

HTML5 中 div section article 的区别 div HTML Spec: “The div element has no special meaning at all.” 这个标签是我们见得最多、用得最多的一个标签。本身没有任何语义，用作布局以及样式化或脚本的钩子(hook)。 section HTML Spec: “The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.” 与 div 的无语义相对，简单地说 section 就是带有语义的 div 了，但是千万不要觉得真得这么简单。section 表示一段专题性的内容，一般会带有标题。看到这里，我们也许会想到，那么一篇博客文章，或者一条单独的评论岂不是正好可以用 section 吗？接着看: “Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the elemen.” ...

CSS注释语法

CSS注释语法 /* 注释内容 */ 示例 /* ----------文字样式开始---------- */ /* 梦之都白色12象素文字 */ .dreamduwhite12px { color:white; font-size:12px; } /* 梦之都黑色16象素文字 */ .dreamdublack16px { color:black; font-size:16px; } /* ----------文字样式结束---------- */

HTML template, 模板

HTML template, 模板 <!DOCTYPE html> <html> <head> <meta charset="utf-8">  <style> body { background-color: powderblue; } </style>  <script src="path/to/foo.js"></script> <script type="text/javascript"> var myVar = "hello"; function showAlert() { alert('You triggered an alert!'); } function func0() { console.log('func0') var outerDiv = document.getElementById('div_0'); // 获取最外层 div 元素的内容 var outerDivContent = outerDiv.childNodes; // 过滤出文本节点 var textContent = ''; outerDivContent.forEach(function (node) { if (node.nodeType === Node.TEXT_NODE) { textContent += node.textContent.trim() + '\n'; } }); // 输出结果 console.log(textContent.trim()); } window.onload = function () { console.log('window.onload') } </script>  <link rel="stylesheet" type="text/css" href="foo.css"> </head> <body> body0 <button type="button" onclick="func0()">button0</button> <div id="div_0" style="background: red"> text_0 <div id="div_1" style="background: green; width: 100px;"> text_1 </div> text_2 </div> </body> </html> # 在浏览器里直接访问这个文件 file:///home/wiloon/tmp/foo.htm HTML (Document Structures) ...

代理服务器

代理服务器代理服务器不仅可以为局域网内的PC提供代理服务，还可以为基于Windows网络的用户提供代理服务。而且代理服务的实现十分简单，它只需在局域网的一台服务器上运行相应的服务器端软件即可。目前代理服务器软件产品主要有: Microsoft Proxy，Microsoft ISA，WinProxy、WinGate、winRoute、SyGate、CCProxy、SuperProxy等；而在UNIX/Linux系统主要采用Squid和Netscape Proxy等服务器软件作为代理。 squid 在Unix/linux下使用的比较优秀的代理服务器软件Squid。之所以说它比较优秀，是因为它可以在代理服务器上作一个很大的缓存，可以把好多常去的网站内容存储到缓存中，这样，内部网的机器再访问那些网站，就可以从缓存里调用了。这样一方面可以加快内部网浏览因特网的速度，这就是所谓的提高客户机的访问命中率；另一方面，Squid不仅仅支持HTTP协议，而且还支持FTP，GOPHER，SSL和WAIS等协议。考虑到简捷实用的原则，squid作为代理服务器不仅性能优异，而且还详细的纪录了各个客户端的访问纪录Squid是一个缓存internet数据的一个软件，它接收用户的下载申请，并自动处理所下载的数据。Squid可以工作在很多的操作系统中，如AIX， Digital Unix， FreeBSD， HP-UX， Irix， Linux， NetBSD， Nextstep， SCO， Solaris，OS/2等，也有不少人在其他操作系统中重新编译过Squid。由于它安装简单，使用方便，所以已经被广泛使用。 1 Microsoft Proxy Server Microsoft Proxy Server是把对Intemet的访问带入一个组织内部每一个桌面上去的一种容易而又安全的方法，它包括Web Proxy服务器，Winsock Proxy服务器和Socks Proxy服务器。Web Proxy为Cache类代理软件，Winsock Proxy通过Winsock协议代理使LAN内的计算机好像直接连接在上一级网络上一样，实际上是通过代理服务器发送请求，但客户端要安装 Microsoft Winsock Proxy Client软件。Microsoft ProxyServer 2.0是Microsoft Bank Ofice客件之一，运行在Windows NT 或Windows 2000环境下。在Windows NT Server4.0上安装时，必须安装3.0或更高版本的IIS(Internet InformationServer)及Windows Service Pack 3或更高版本的补丁。它容易与安全地安装，充分利用内建在Windows NTServer里的安全性，并允许网络操作员对进入或来自Intemet的访问作有效地控制。它支持全部的Internet协议包括HTTP、FTP、 Gopher、RealAudio、VDOfive、IRC、邮件和新闻协议，支持IPX/SPX和TCP/IP协议来容易访问Intemet服务器以及内部网上的应用软件。它提供超高速缓存，保存网络带宽，改善客户机的响应时问，减少网络的拥挤，并且在不加重最终用户和网络管理员负担的情况下改善对网络资源的控制。管理员可以根据用户、服务、端口或IP域来允许或拒绝入站或出站的连接，可以阻止对一些指定站点的访问，但不能采用直接导入方法来设定允许访问站点地址。它与NT网络系统管理服务集成，ProxyServer生成一套Windows NT Performance Counters来监视网络上任何一台代理服务器的状态，与Windows NT ServerDirectory Services集成来用户等级的验证。井提供防火墙等Intemet安全认证特性。 2 Wingate Wingate是Qbic公司的产品，软件分为服务器和客户两部分。服务器可运行于Win 98或Win NT平台，提供用户认证，各种网络应用层协议代理，Intemet访问控制，包过滤等服务;客户部分为一个用户登录程序Gatekeeper，用户使用它在代理服务器上进行登录，代理服务器将用户的IP地址与相应用户账号绑在一起。如果这一用户是管理员，还可以使用Gatekeeper进行远程管理。 Wingate支持双网络接口，一个接口通过网络适配器卡连接内部局域网络，另一个网络接口连接Intemet，两块网卡问的IP转发要禁用，使内部网络与外部网络完全隔开，形成双宿网关防火墙。Wingate也支持单网卡，在许多校园网中，只允许部分计算机具有Intemet访问权，利用这些计算机作为代理服务器，为其他的计算机提供服务，只是它不具备防火墙的功能。Wingate除了提供FTP Proxy、Telnet Proxy、 POP3 Proxy、RealAudio Proxy、Socks Pmxy代理服务之外，还提供了DNS、DHCP、拨号管理等丰富功能。 3 SyGate ...

html tag

html tag [code lang=html] HTML 标签以下代码标记了一个段落: This is some text in a very short paragraph inpiut type: button checkbox file hidden image password radio reset submit text 规定 input 元素的类型。 value: 定义input 元素的值。 textarea: 定义多行的文本输入控件

golang log

golang log seelog https://github.com/cihub/seelog log, glog, logrus https://sites.google.com/site/kjellhedstrom2/g2log-efficient-background-io-processign-with-c11/g2log-vs-google-s-glog-performance-comparison https://logmatic.io/blog/our-guide-to-a-golang-logs-world/ https://www.goinggo.net/2013/11/using-log-package-in-go.html http://legendtkl.com/2016/03/11/go-log/ log 首先是golang自带的package log。使用godoc查看，godoc -http=:8001，然后就可以在localhost:8001/pkg/log就可以查看了。最重要的是SetOutput这个函数，原型是func SetOutput(w io.Writer),决定了log应该输出到什么地方，默认是标准输出。下面是把log输出到文件的一个简单代码示例。 package main import ( “log” “os” ) func main() { f, err := os.OpenFile(“logfile.log”, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) if err != nil { log.Fatalf(“file open error : %v”, err) } defer f.Close() log.SetOutput(f) log.Println(“This is a test log entry”) } 我们此时打开文件logfile.log，会看到文件内容如下。 2016/03/11 17:54:10 This is a test log entry 有时候我们并不需要前面的日期以及时间信息，比如做自动化测试的时候比对log肯定不希望有时间信息。那应该怎么办呢？这时候就该SetFlags()出场了。 package main import ( “log” “os” ) func main() { f, err := os.OpenFile(“logfile.log”, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666) ...

Session

Session session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。 session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个 session。有时候我们可以看到这样的话"在一个浏览器会话期间，…"，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间 ①。最混乱的是"用户 (客户端) 在一次会话期间"这样一句话，它可能指用户的一系列动作 (一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction) ，然而有时候也可能仅仅是指一次连接，也有可能是指含义①，其中的差别只能靠上下文来推断②。然而当session一词与网络协议相关联时，它又往往隐含了"面向连接"和/或"保持状态"这样两个含义， “面向连接"指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，与此相对的是写信，在你把信发出去的时候你并不能确认对方的地址是否正确，通信渠道不一定能建立，但对发信人来说，通信已经开始了。“保持状态"则是指通信的一方能够把一系列的消息关联起来，使得消息之间可以互相依赖，比如一个服务员能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有"一个TCP session"或者 “一个POP3 session"③。而到了web服务器蓬勃发展的时代，session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候session也用来指这种解决方案的存储结构，如"把xxx保存在session 里"⑤。由于各种用于web开发的语言在一定程度上都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决方案，比如经常把Java里提供的javax.servlet.http.HttpSession简称为session⑥。鉴于这种混乱已不可改变，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。在本文中，使用中文"浏览器会话期间"来表达含义①，使用"session机制"来表达含义④，使用"session"表达含义⑤，使用具体的"HttpSession"来表达含义⑥ HTTP协议与状态保持 HTTP 协议本身是无状态的，这与HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或者一个普通的 (非会员制) 大卖场之间的关系一样。然而聪明 (或者贪心？) 的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能一样。这种需求一方面迫使HTML逐步添加了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议也添加了文件上载、 cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案: 该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。理解cookie机制 cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决: “会员卡"如何分发；“会员卡"的内容；以及客户如何使用"会员卡”。正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。而cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示，如果某家分店还发行了自己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。 cookie的内容主要包括: 名字，值，过期时间，路径和域。其中域可以指定某一个域比如 .google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如 www.google.com 或者 froogle.google.com，可以用飘柔来做比。路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。路径与域合在一起就构成了cookie的作用范围。如果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie 可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按 Ctrl-N (或者从文件菜单) 打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于 Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很大的困扰。下面就是一个goolge设置cookie的响应头的例子 HTTP/1.1 302 FoundLocation: http://www.google.com/intl/zh-CN/Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.comContent-Type: text/html 这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分 ...

remember me

remember me jwt http://blog.daocloud.io/5700.html spring security http://www.semlinker.com/spring-security-remember-me/ https://www.cnblogs.com/zongmin/p/13783285.html restful api remember me https://blog.csdn.net/liukangjie520/article/details/111617244 https://xie.infoq.cn/article/f83774aa8603152a82105ab69

favicon

favicon 所谓favicon，即Favorites Icon的缩写，顾名思义，便是其可以让浏览器的收藏夹中除显示相应的标题外，还以图标的方式区别不同的网站。当然，这不仅仅是Favicon的全部，根据浏览器的不同，Favicon显示也有所区别: 在大多数主流浏览器如FireFox和Internet Explorer (5.5及以上版本)中，favicon不仅在收藏夹中显示，还会同时出现在地址栏上，这时用户可以拖曳favicon到桌面以建立到网站的快捷方式；除此之外，标签式浏览器甚至还有不少扩展的功能，如FireFox甚至支持动画格式的favicon等。在我们的网站建设中，为网站打造一个契合网站主题的个性化标志则是必需的，这直接关系到能否成功地塑造网站的品牌。这从某些角度看仍在网站推广的范畴之内，而欲取得成功，不仅包括良好的页面设计、令人印象深刻的网站Logo，也包括favicon。favicon显示位置,从特定的技术角度看，favicon也并不只是仅仅让网站给人更专业的观感，也可以在一定程度上减轻服务器的流量带宽占用: 一般为了提高网站的可用性，我们都会为自己的网站创建一个自定义的404错误文件，在这种情况下，如果网站没有相应的favicon.ico文件，每当有用户收藏网站/网页时， Web服务器都会调用这个自定义的404文件，并在网站的错误日志中记录。这显然是应该予以避免的。如何制作Favicon.ico 制作Favicon.ico的方法相当简单，首先，利用图形工具创建2个反映网站主题的256色的小图片: 1个为32×32像素，另一个为16 ×16像素。需要注意的是，调色板要选用"Windows 默认调色板"，不然，在最终的效果展示中图形可能会发生迥异于您初衷的颜色上变化。需要说明的是，在很多关于Favicon.ico的说明中，常见到要求图片为16色的说法，应该说这类说法大大过时: 在早期如Windows 95时期，16色的Favicon.ico可能是个稳妥的选择，保证其在大多数情况下正常使用，但现在，完全不存在那类限制，16色只能使图标的展示效果大大降低。至于在浏览器中使用时16×16像素的图片已经足够，为什么还要准备32×32像素的图片，原因在于，正如上文所言，favicon也显示在地址栏中，用户可以拖曳favicon到桌面以建立到网站的快捷方式，而桌面图标则要以32×32显示的，如果您的Favicon.ico不包括32像素的图片，系统就只能使用默认的浏览器图标来标注网站/网页，如Internet Explorer的蓝色"e"，起不到我们意欲通过Favicon.ico打造网站品牌的作用。图片制作好后，使用如Image2Ico之类的小程序即可将2张图片转换到一个Icon文件中在网页中使用Favicon.ico 浏览器调用Favicon的原则是首先在网页所在的目录下寻找Favicon.ico文件，如果没有，便到网站的根目录下寻找。因此，在网页中使用Favicon最简单的办法便是将制作好的图标文件命名为Favicon.ico，然后将其上传到网站的根目录即可。如果您需要将Favicon.ico放到其他目录下，或者希望让不同的网页显示不同的Favicon，就需要在网页Html文件中做设定了，具体设置也很简单，在Html中的<head>部分加入如下的代码: 程序代码:

robots.txt

robots.txt robots.txt (统一小写) 是一种存放于网站根目录下的ASCII编码的文本文件，它通常告诉网络搜索引擎的漫游器 (又称网络蜘蛛) ，此网站中的哪些内容是不能被搜索引擎的漫游器获取的，哪些是可以被 (漫游器) 获取的。因为一些系统中的URL是大小写敏感的，所以robots.txt的文件名应统一为小写。robots.txt应放置于网站的根目录下。如果想单独定义搜索引擎的漫游器访问子目录时的行为，那么可以将自定的设置合并到根目录下的robots.txt，或者使用robots元数据。 Robots.txt协议并不是一个规范，而只是约定俗成的，所以并不能保证网站的隐私。注意Robots.txt是用字符串比较来确定是否获取URL，所以目录末尾有和没有斜杠"/“这两种表示是不同的URL，也不能用"Disallow: *.gif"这样的通配符。其他的影响搜索引擎的行为的方法包括使用robots元数据: <meta name="robots" content="noindex,nofollow" /> 这个协议也不是一个规范，而只是约定俗成的，通常搜索引擎会识别这个元数据，不索引这个页面，以及这个页面的链出页面。

Closure Tools

Closure Tools Google已经基于Apache License 2.0把Closure Stylesheets开源，这种工具属于Closure Tools包之内，在处理CSS的时候很有用。Closure Stylesheets是一个Java程序，它向CSS中添加了变量、函数、条件语句以及混合类型，使得我们更易于处理大型的CSS文件。开发者可以使用Google stylesheets (GSS)这种工具来生成web应用程序或者网站所使用的真正的CSS文件。 http://www.infoq.com/cn/news/2011/11/Google-Closure-Stylesheets

tomcat config, server, user

tomcat config, server, user server Listener 监听器，用来监听某些事件的发生。 VersionLoggerListener，启动时对tomcat，java，操作系统信息打印日志。 JreMemoryLeakPreventionListener, JreMemoryLeakPreventionListener，防止内存溢出的监听器。 http://liuxi.name/blog/20160608/jvm-full-gc-hourly.html GlobalResourcesLifecycleListener，初始化定义在元素GlobalNamingResources下的全局JNDI资源 ThreadLocalLeakPreventionListener，防止ThreadLocal溢出监听器。 connectionTimeout - 网络连接超时，单位: 毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。 keepAliveTimeout - 长连接最大保持时间 (毫秒) user config Tomcat 6 <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <role rolename="manager"/> <role rolename="admin"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user username="admin" password="admin" roles="admin,manager"/> <user username="hhh" password="123456" roles="role1,tomcat,admin,manager"/> </tomcat-users> Tomcat 7 <role rolename="manager"/> <role rolename="manager-gui"/> <role rolename="admin"/> <role rolename="admin-gui"/> <user username="tomcat" password="tomcat" roles="admin-gui,admin,manager-gui,manager"/>

WS-I

WS-I WS-I是Web Services Interoperability Organization的缩写，意为网络服务协同组织。WS-I (Web Services Interoperability Organization) 于2002年2月6日由包括微软、IBM、SAP、ORACLE、Intel等在内的9家IT行业领袖和46家公司联合宣告成立。业界对于WS-I的关注首先在于对网络服务兼容性将带来的重要影响；另一方面，尽管该组织联合了众多竞争对手的参与，但是在网络服务技术方面作为微软公司最直接、最据威胁的竞争对手的SUN公司并未参与这项联盟。 WS-I提出了3个目标: (1) 为客户的网络服务应用提供实施指导和培训； (2) 促进跨平台、跨应用软件和跨程序语言的网络服务的一致和兼容，并保证可靠兼容； (3) 致力于使网络服务协同成为本行业共同遵守的准则，以帮助客户在网络服务技术的选择上轻松决策，提高网络服务的应用范围和水平，并确保网络服务技术的持续发展。为实现上述目标，WS-I计划开展下面的工作: (1) 提供网络服务测试和实施指导 (测试网络服务是否符合标准来确保他们能够成功集成) ，以促进客户的网络服务应用; (2) 提供网络服务系统框架，支持和推动关键网络服务标准的使用； (3) 发布网络服务技术路标规划，帮助客户了解网络服务解决方案的长期发展方向。 WS-I为Web服务开发商提供了一系列资源，这些资源可以帮助他们创建可互操作的Web服务并验证他们的结果是否遵从WS-I的指导方针。WS-I的主要成果包括概要，应用样本和测试工具。概要为相关Web服务更好的一起互操作的使用提供了实现的指导方针。直到今日，WS-I已经定稿的有Basic Profile，Attachments Profile和简单SOAP绑定Profile。Basic Security Profile还在指定当中。应用样本演示了符合WS-I知道方针的Web服务应用。这些实现的开发运用了多种平台、语言和开发工具，并演示了互操作性，为Web服务开发厂商提供了可用的资源。应用样本作为应用的实例可以作为参考让开发商在他们自己特有的环境下遵循WS-I的指导方针。直至今日，WS-I已经为Basic Profile实现了11个应用样本。测试工具是用来测试Web服务的消息交换是否遵循WS-I的指导方针。这些工具监控消息并分析结果来确定是哪些互操作问题。这些测试能力对开发商来说很重要，这样才能确保他们在运用Web服务规范下的实现遵从现在的互操作指导方针。测试是在自我管理下进行的，目的是为了发现规范实现中非传统的用法和错误，这样可以帮助改善应用和平台间的互操作性。直至今日，WS-I已经为开发商开发的测试工具可以核实与Basic Profile1.0的一致性，有关其他WS-I profile的测试工具的制定还在进行中。

html5 video

html5 video HTML5 video 元素支持三种视频格式: Ogg = 带有 Theora 视频编码和 Vorbis 音频编码的 Ogg 文件 MPEG4 = 带有 H.264 视频编码和 AAC 音频编码的 MPEG 4 文件 WebM = 带有 VP8 视频编码和 Vorbis 音频编码的 WebM 文件

CXF Axis2

CXF Axis2 http://apache-cxf.group.iteye.com/group/wiki/1252 新一代的 Web Services 框架如 Axis2、CXF 都是由现有的项目中逐渐演化而来的，Axis2 是由大家熟悉的 Axis 1.x 系列演化过来，而 Apache CXF 则是由 Celtix 和 XFire 项目整合而生，并且刚刚发布了 2.0.2 的最新版本，不过仍是 Apache 的一个孵化项目。 Axis2 是对 Axis 进行了彻底的重写的一个新项目了，它使用了新的模块化架构，更方便于功能性的扩展等等。 Apache CXF 则是由 XFire 和 Celtix 两个现有的项目进行了重组。问题: 如果现有的应用程序是基于 Axis 1.x、XFire 或者 Celtix 的话，那应该怎么办？都迁移到这些新的框架上去吗？但是即使是要迁移，那应该迁移到哪个框架上去呢？如果是编写一个新的 Web Services 应用程序的话，就不存在迁移的问题了，但是哪个框架是你应当选择进行使用的呢？哪个比哪个更好呢？对于现在的应用程序的迁移，如果你的应用程序是稳定而成熟的，并且在可预知的未来的情况下，只要很少的一些需求变更要做的话，那么保存你的体力，不要去做"劳民伤财"的迁移工作了。如果你的现有应用程序BUG缠身，性能，功能等等都一片糟糕的话，那就要考虑迁移了，那选哪个框架呢？先比较一下它们的不同之处: Apache CXF 支持 WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-I BasicProfile Axis2 支持 WS-Addressing、WS-RM、WS-Security和WS-I BasicProfile，WS-Policy将在新版本里得到支持 Apache CXF 是根据Spring哲学来进行编写的，即可以无缝地与Spring进行整合 Axis2 不是 Axis2 支持更多的 data bindings，包括 XMLBeans、JiBX、JaxMe 和 JaxBRI，以及它原生的 data binding (ADB) 。 ...

JAX-WS

JAX-WS JAX-WS规范是一组XML web services的JAVA API。JAX-WS允许开发者可以选择RPC-oriented或者message-oriented 来实现自己的web services。在 JAX-WS中，一个远程调用可以转换为一个基于XML的协议例如SOAP。在使用JAX-WS过程中，开发者不需要编写任何生成和处理SOAP消息的代码。JAX-WS的运行时实现会将这些API的调用转换成为对应的SOAP消息。在服务器端，用户只需要通过Java语言定义远程调用所需要实现的接口SEI (service endpoint interface) ，并提供相关的实现，通过调用JAX-WS的服务发布接口就可以将其发布为WebService接口。在客户端，用户可以通过JAX-WS的API创建一个代理 (用本地对象来替代远程的服务) 来实现对于远程服务器端的调用。当然 JAX-WS 也提供了一组针对底层消息进行操作的API调用，你可以通过Dispatch 直接使用SOAP消息或XML消息发送请求或者使用Provider处理SOAP或XML消息。通过web service所提供的互操作环境，我们可以用JAX-WS轻松实现JAVA平台与其他编程环境 (.net等) 的互操作。 JAX-WS与JAX-RPC之间的关系 Sun最开始的web services的实现是JAX-RPC 1.1 (JSR 101)。这个实现是基于Java的RPC,并不完全支持schema规范，同时没有对Binding和Parsing定义标准的实现。 JAX-WS2.0 (JSR 224)是Sun新的web services协议栈，是一个完全基于标准的实现。在binding层，使用的是the Java Architecture for XML Binding (JAXB, JSR 222)，在parsing层，使用的是the Streaming API for XML (StAX, JSR 173)，同时它还完全支持schema规范。

input tag

input tag Optional Attributes: type: button,…. value:Specifies the value of an input element Event Attributes: ondblclick: Script to be run on a mouse double-click.

网关,路由

网关,路由网关网关实质上是一个网络通向其他网络的IP地址。比如有网络A和网络B 网络A的IP地址范围为"192.168.1.1~192.168.1.254"，子网掩码为255.255.255.0 网络B的IP地址范围为"192.168.2.1~192.168.2.254"，子网掩码为255.255.255.0 在没有路由器的情况下，两个网络之间是不能进行TCP/IP通信的，即使是两个网络连接在同一台交换机 (或集线器) 上，TCP/IP协议也会根据子网掩码 (255.255.255.0) 判定两个网络中的主机处在不同的网络里。而要实现这两个网络之间的通信，则必须通过网关。如果网络A中的主机发现数据包的目的主机不在本地网络中，就把数据包转发给它自己的网关，再由网关转发给网络B的网关，网络B的网关再转发给网络B的某个主机。网络B向网络A转发数据包的过程也是如此。只有设置好网关的IP地址，TCP/IP协议才能实现不同网络之间的相互通信。那么这个IP地址是哪台机器的IP地址呢？网关的IP地址是具有路由功能的设备的IP地址，具有路由功能的设备有路由器、启用了路由协议的服务器 (实质上相当于一台路由器) 、代理服务器 (也相当于一台路由器) 。默认网关如果搞清了什么是网关，默认网关也就好理解了。就好像一个房间可以有多扇门一样，一台主机可以有多个网关。默认网关的意思是一台主机如果找不到可用的网关，就把数据包发给默认指定的网关，由这个网关来处理数据包。现在主机使用的网关，一般指的是默认网关。默认网关必须是电脑自己所在的网段 (将IP地址和子网掩码作与运算，得到网段) 中的IP地址，而不能填写其他网段中的IP地址。自动网关自动网关设置就是利用DHCP服务器来自动给网络中的电脑分配IP地址、子网掩码和默认网关。这样做的好处是一旦网络的默认网关发生了变化时，只要更改了DHCP服务器中默认网关的设置，那么网络中所有的电脑均获得了新的默认网关的IP地址。这种方法适用于网络规模较大、TCP/IP参数有可能变动的网络。路由器理解IP路由器原理及工作机制一个路由器其实就是一个超小型的电脑，而且操作系统大多为Linux，但是在做这些操作的时候你可能并不知道IP路由是如何工作的。本文将助你理解IP路由的原理，以及它是如何工作的。 IP路由涉及到IP数据报文的转发。如果主机与目的主机直接相连，那么主机可以直接发送IP报文到目的主机，这个过程比较简单。例如，通过点对点的链接或通过网络共享。如果主机与目的主机没有直接相连，那么主机会将IP报文发送给默认的路由器，然后由路由器来决定往哪发送IP报文。普通的主机与路由器之间的根本区别在于，主机不会将一个报文从一个接口转发到另一个接口，而路由器可以转发报文，大多数的多用户系统都可以被配置，从而被当作路由器来用。因此，一个普通路由算法可以被用在路由器上，同样也可以用在一台普通主机上。当一台主机可以用作路由器时，我们通常说这台主机嵌入了路由器的功能。这种具备嵌入路由器功能的主机平常不会转发报文，除非我们对它进行了配置，使它开启这种功能。 IP层维护着一张路由表，当收到数据报文时，它用此表来决策接下来应该做什么操作。当从网络侧接收到数据报文时，IP层首先会检查报文的IP地址是否是主机自身的地址相同，如果数据报文中的IP地址是主机自身的地址，那么报文将被发送到传输层相应的协议中去。如果报文中的IP地址不是主机自身的地址，并且主机配置了具备路由的功能，那么报文将被转发;否则，报文就被丢弃。路由表中的数据一般是以条目形式存在，路由表条目包含以下主要的条目项: 目的IP地址: 此字段表示目标的IP地址。这个IP地址可以是某一台主机的地址，也可以是一个网络地址。如果这个条目包含的是一个主机地址，那么它的主机ID标记为非零;如果这个条目包含的是一个网络地址，那么它的主机ID被标记为零。下一个路由器的IP地址: 为什么我们使用"下一个"的说法，是因为下一个路由器并不总是最后的目的路由器，但它很可能是一个中间路由器。条目给出下一个路由器的地址是用来转发从相应接口收到的IP数据报文。标志: 这个字段提供了另一组重要信息，如目的IP地址(之前提到的)是一个主机地址还是一个网络地址。此外，从标志中可以得知下一个路由器(之前提到的)真的是一个路由器还是一个直接相连的接口。网络接口规范: 一些数据报文的网络接口规范，这个规范跟随报文一起传播。如果我们现在想简单而形象地描述路由过程，我们将会看到: 一旦主机(被配置成具备路由功能)的IP层接收到从网络侧来的数据报文，它将核实数据包中的目的IP地址，如果此IP不是主机的IP地址，那么包将通过路由表转发。如果任何条目的第一个字段完全匹配目的IP地址或部分匹配目的IP地址，那么它将指示下一个路由器的IP地址。这是一个重要的信息，因为这些信息直接告诉主机数据包应该转发到哪一个"下一个路由器"去。而条目中所有其它的字段将提供更多辅助的信息来为路由转发做决定。首先，路由表会去搜索一个"目的IP地址"字段与数据报文中目的IP地址完全相同的条目。这就意味着IP地址的主机ID与网络ID完全的匹配。如果找到，则数据包被发送到相应接口或中间路由器。如果没有找到一个完全的匹配IP，那么就接着搜索相匹配的网络ID。如果找到，那么该数据报文会被转发到指定的路由器。所以我们看到，这个网络上的所有主机都通过这个路由表中的单个(这个)条目来管理。如果上述步骤失败，即没有默认路由器，那么该数据报文最终无法被转发。任何无法投递的数据报文都将产生一个ICMP主机不可达或ICMP网络不可达的错误，并将此错误返回给生成此数据报文的应用程序。在路由表中包含与网络相关的路由条目是一个很大的优点。其优点在于，拥有一个与完整网络相关的条目，能够避免包含此网络中所有单独的主机条目，这使得路由表的大小降到一个可收受的数量级，这样就非常好。网关和路由器的区别对于路由器的设置，很多朋友们都还不大了解，或许听过，但是设置的时候会很迷糊，不知道如何下手。设置宽带路由器时，你会发现在在"高级路由"设置中有两个选项: 网关和路由器。今天我们来讲讲这两个的区别。网关简而言之，网关是网络的进口和出口 (网关还有其他功能，如协议翻译……) ，网关定义网络的边界。路由器使用一系列算法决定网络间的最短路径。路由器使用静态路由或动态路由来决定网络间的最短路径。静态路由需要管理员手动设置，而动态路由使用一些协议来动态发现网络间的路径并判断最短路径。通常，对于小型网络使用静态路由，大型复杂网络使用动态路由。现在，路由器集成了网关的功能，所以路由器也具有网关的功能。从网关和路由器的定义来看，如果只是简单地连接两个网络，那么只需要网关就足够了。假定只有两个网络: 网络A和网络B 要使网络A和网络B能够通信，只使用网关将这两个网络连接即可，因为只有两个网络，不需要决定网络间最短路径。如果需要连接多个网络，为了保证网络的可靠性，网络结构需要设计为全网状或部分网状，这样，为了网络间的通信，需要网关和路由器两种设备，因为当前路由器集成了网关的功能，所以只使用路由器一种设备就可以了。假定有4个网络: 网络A、网络B、网络C、网络D 要使这4个网络之间能够通信，另外为了保证网络的可靠性，将这4个网络进行全网状连接，如下图: 例如，此时从网络A到网络D就有两条路径，所以需要使用路由器来决定网络间的最短路径。下面来看看宽带路由器中"高级路由"中的网关和路由器选项: 网关: 如果此宽带路由器是网络上唯一一台连接Internet的路由器，选择网关。此时宽带路由器作为网络的进/出口。计算机基础教程路由器: 如果网络中还有其他路由器，选择路由器。总结: 1、对于家庭共享上网，只需要使用网关即可，所以在宽带路由器中选择"网关"选项 2、对于大型企业网络内部，或大型企业网络连接Internet，由于网络中可能存在其他路由器，所以应当选择宽带路由器中的"路由器"选项，以决定网络间的最短路径 PS: 默认网关有时在Windows中设置网络时，我们经常会看到"默认网关"的设置 ...

HTTP protocol， HTTP response status codes, 状态码/响应代码

HTTP protocol， HTTP response status codes, 状态码/响应代码 http header RFC 2616 规范说明了处理 HTTP Header 应该是大小写不敏感的。 Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. golang gin 默认会把 header name 转成首字母大写 Envoy 默认会将 Header 转换为小写 Envoy 只支持两种规则：全小写 (默认使用的规则) 首字母大写 (默认没有启用) User-Agent 标识用户代理 Referer 告诉服务器用户从哪里来 If-Modified-Since 主要用来检查cache是否过期超文本传输协议(HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的www文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。 1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本 (hypertext) ,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会 (World Wide Web Consortium) 和Internet工作小组 (Internet Engineering Task Force) 共同合作研究，最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议的我们今天普遍使用的一个版本HTTP 1.1。 ...

chart library

chart library web chart library chartjs Simple yet flexible JavaScript charting https://www.chartjs.org/ Apache ECharts An Open Source JavaScript Visualization Library https://echarts.apache.org/en/index.html