rfc

前端必须会的!!!关于对HTTP协议的理解、HTTP协议原理分析

匆匆过客 提交于 2019-11-28 22:11:15
http协议 学习系列 1. 基础概念篇 1.1 介绍 HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写。它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定义了今天普遍使用的一个版本——HTTP 1.1。 HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。 HTTP是一个应用层协议,由请求和响应构成,是一个标准的客户端服务器模型。HTTP是一个无状态的协议。 1.2 在TCP/IP协议栈中的位置 HTTP协议通常承载于TCP协议之上,有时也承载于TLS或SSL协议层之上,这个时候,就成了我们常说的HTTPS。如下图所示: 默认HTTP的端口号为80,HTTPS的端口号为443。 1.3 HTTP的请求响应模型

What date RFC does Twitter use?

独自空忆成欢 提交于 2019-11-28 13:23:51
Doc use : Tue Apr 07 22:52:51 +0000 2009 as an example. Can anyone identify the rfc? Cheers I can't say "there is no standard of that format" of course, because I very well may have just missed it. But when I started working with the Twitter API I did search for awhile to find the standard they are using and couldn't find a match. I ended up having to define a custom format (c#): DateTime.ParseExact(twitterDateString, "ddd MMM dd HH:mm:ss %K yyyy", CultureInfo.InvariantCulture.DateTimeFormat); msw Neither RFC 2822 nor RFC 3339 allow for separating the year from the month and day like that. If

Is Oracle's SYS_GUID() UUID RFC 4122 compliant?

拈花ヽ惹草 提交于 2019-11-28 07:22:57
I wonder if Oracle's SYS_GUID() function returns a RFC 4122 compliant UUID . For example: SQL> select sys_guid() from dual; SYS_GUID() -------------------------------- A6C1BD5167C366C6E04400144FD25BA0 I know, that SYS_GUID() returns a 16 byte RAW datatype. Oracle uses RAWTOHEX() and probably TO_CHAR() to print out the above ID. Is it correct to interpret this as a UUID compliant string format like: A6C1BD51-67C3-66C6-E044-00144FD25BA0 I think it's not compliant to the RFC 4122 standard, because the definition says, that a valid UUID must name the UUID-Version within the UUID itself. Syntax for

Extract Server Name Indication (SNI) from TLS client hello

China☆狼群 提交于 2019-11-28 06:33:31
How would you extract the Server Name Indication from a TLS Client Hello message. I'm curently struggling to understand this very cryptic RFC 3546 on TLS Extensions, in which the SNI is defined. Things I've understood so far: The host is utf8 encoded and readable when you utf8 enocde the buffer. Theres one byte before the host, that determines it's length. If I could find out the exact position of that length byte, extracting the SNI would be pretty simple. But how do I get to that byte in the first place? I did this in sniproxy , examining a TLS client hello packet in Wireshark while reading

tomcat采坑

时光毁灭记忆、已成空白 提交于 2019-11-28 00:37:26
采坑 今天又踩了个以前踩过的坑,运维系统迁移到docker,使用的tomcat版本是tomcat8,而原来的版本是tomcat7.0.53,导致的结果就是系统间请求一直报 400 code 错误 发现改成POST请求,用idea的test方法调用是通的,然后用postman这类工具就是500 code错误,真是千奇百怪的 然后依次偶然,我直接把请求复制到浏览器上调用,出现的错误信息中包含了 The valid characters are defined in RFC 7230 and RFC 3986 我知道这可能是唯一能找到其根源的机会了,因为就算是浏览器调用也不是每次都会出现这么详细的错误,很多时候就是个小小的400 解决 之后查到解决办法,参考 此篇文章 , Tomcat在 7.0.73, 8.0.39, 8.5.7 版本后,在http解析时做了严格限制。 可以降tomcat版本,或改配置 来源: https://www.cnblogs.com/sky-chen/p/11383175.html

Can . (period) be part of the path part of an URL?

三世轮回 提交于 2019-11-27 21:31:30
问题 Is the following URL valid? http://www.example.com/module.php/lib/lib.php According to http://tools.ietf.org/html/rfc1738 section the hpath element of an URL can not contain a '.' (period). There is in the above case a '.' after "module" which is not allowed according to RFC1738. Am I reading the RFC wrong or is this RFC succeed by another RFC? Some other RFC's allows '.' in URLs (http://tools.ietf.org/html/rfc1808). 回答1: I don't see where RFC1738 disallows periods (.) in URLs. Here are some

网络

故事扮演 提交于 2019-11-27 18:19:22
UDP,User Datagram Protocol):用户数据报协议,UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据报的方法。RFC 768 [1] 描述了 UDP。 TCP,Transmission Control Protocol:传输控制协议,是一种面向连接的、可靠的、基于字节流的传输层通信协议,有IETF的RFC 793定义 TCP三大步骤:   1,创建链接   2,数据传送   3,终止连接 来源: https://www.cnblogs.com/yifengs/p/11371991.html

How to overcome root domain CNAME restrictions?

让人想犯罪 __ 提交于 2019-11-27 16:47:39
We are hosting many web applications for our customers. As is obvious they want to use their own domains to refer to those applications, usually they want that any user that either type http://www.customer1.example or http://customer1.example goes to their web application. The situation we are facing is that we need to have the flexibility to change IP addresses in the near future. And we don't want to rely on the customer doing the A record change on their domains. So we thought that using CNAME records will work, but as we find out CNAME records will not work for the root domain. Basically:

Are email addresses case sensitive?

坚强是说给别人听的谎言 提交于 2019-11-27 16:47:29
I've read that by standard first part of e-mail is case sensitive, however I've tried to send e-mail to name@example.com , Name@example.com and NAME@example.com - it has arrived in each case. How do mail servers handles usernames? Is it possible to miss with case and that message wouldn't be delivered? Is it really very important to use exactly same letter case, as was written while registering when giving your e-mail address? From RFC 5321, section-2.3.11: The standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications

HCNA --- 计算机网络基础

喜夏-厌秋 提交于 2019-11-27 16:00:41
数据 是指以任何格式表示的信息,数据的格式需要信息的创建者和接收者提前达成共识。比如一幅图片可以抽象成由无数个像素组合在一起,再用其它方式表示一个像素,这样就能实现把一幅图片存储在存储介质上。常用的信息有文本、数字、图像、音频和视频等形式。 数据通信 是指两台设备之间通过线缆、传输设备等形式的传输介质进行数据交换的过程。 一个完整的数据通信系统应该由报文、发送方、接收方、介质和协议五个部分组成。 报文 (message):报文是指通讯中的数据块。文本、数字、图片、声音、视频等信息被编码后,以报文的形式被传送。 发送方 (sender):发送方是指发送数据报文的设备。它可以是计算机、工作站、服务器、手机等。 接收方 (receiver):接受方是指接收报文的设备。它可以是计算机、工作站、服务器、手机、电视等。 介质 (medium):传输介质:是指信号传送的载体。局域网中常见的传输介质有光纤、同轴电缆、双绞线等。 协议 (protocol):协议是指管理数据通讯的一组规则。它表示通讯设备之间的一组约定。如果没有协议,即使两台设备可能在 物理上是连通的,也不能通讯。比如一个只能说汉语的人就无法被一个只能说英语的理解。 单工 :在单工模式(simplex mode)下,通讯是单方向的。两台设备只有一台能够发送,另一台则只能接收。键盘和显示器都是单工通讯设备。键盘只能用来输入