rfc

HTTP状态码

由 柔情痞子 提交于 2019-12-17 20:31:56
消息编辑 这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。 100 Continue 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。 101 Switching Protocols 服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 102 Processing 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。 成功编辑 这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。 200 OK 请求已成功，请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。 201 Created

Are email addresses case sensitive?

由 天涯浪子 提交于 2019-12-17 15:06:31
问题 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? 回答1: From RFC 5321, section-2.3.11: The standard mailbox naming

Regex for validating multiple E-Mail-Addresses

由 偶尔善良 提交于 2019-12-17 08:30:53
问题 I got a Regex that validates my mail-addresses like this: ([a-zA-Z0-9_\-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([a-zA-Z0-9\-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?) This works perfectly fine, but only allows one e-mail to be entered. Now I wanted to extend that and allow multiple mail-addresses to be added (just like MS Outlook, for example) with a semicolon as a mail-splitter. mail1@tld.com;mail2@tld.com;mail3@tld.com Now I've searched and found this one: ([A-Za-z0-9._%+-]+@[A-Za-z0

JSON Specification and usage of BOM/charset-encoding

由 旧城冷巷雨未停 提交于 2019-12-17 06:48:32
问题 I've been reading up on the RFC-4627 specification, and I've come to interpretation: When advertising a payload as application/json mime-type, there MUST be no BOM s at the beginning of properly encoded JSON streams (based on section "3. Encoding"), and no media parameters are supported, thus a mime-type header of application/json; charset=utf-8 does not conform to RFC-4627 (based on section "6. IANA Considerations"). Are these correct deductions? Will I run into problem when implementing web

Why is form enctype=multipart/form-data required when uploading a file?

由 给你一囗甜甜゛ 提交于 2019-12-17 02:30:33
问题 Why is <form enctype=multipart/form-data> required when uploading a file to a web-server? 回答1: It has to do with how the browser packages binary and form data for transmission over HTTP. By default only form data is sent, but if the form needs to support uploading a file, then the binary data must also be appended and separated from the form data. Scott Hanselman gives a good explanation of this here: HTTP and How File Upload works via HTTP It's always better, for me, to understand WHY and

Why HTTP servers forbid underscores in HTTP header names

由 此生再无相见时 提交于 2019-12-17 02:12:16
问题 Few month ago I had a problem with a custom HTTP header named "SESSION_ID", not been transfered by nginx proxy. I've been told that underscores are prohibited according to RFC of HTTP protocol. Googling, I've found that most servers like apache or nginx define them as illegal. RFC2616 section 4.2 says follow the same generic format as that given in Section 3.1 of RFC 822 [9] and RFC822 says The field-name must be composed of printable ASCII characters (i.e., characters that have values

【译】如何阅读RFC

由 隐身守侯 提交于 2019-12-15 09:43:25
原文： How to Read an RFC 在实验室时，读 RFC 就是一件令人痛苦的事情。今天搬运了一份 RFC 查阅指南，有助于大家查阅的时候保持一个良好的心情。作者是 Charles Eames ，从2000年起就活跃于 IETF，现为 HTTP and QUIC Working Groups 的联席主席。 甭管好坏，请求评论（RFCs）正是今天我们在互联网上定义繁多协议的方式。一开始这些文件会被试图解读它们的开发者奉为圭稚，很快又因为难以理解而被弃之不顾。这种事情令人沮丧，更严重的是会导致互通性和安全上的问题。 但是（ 敲黑板 ），只要了解它们是如何创建和发布的，就会更容易理解它们。以下是我从事 HTTP 和 其他 一些工作中总结出来的经验。 从哪里开始 获取 RFC 文件的标准地方是 RFC Editor Web Site 。但是，正如下面将会看到的，这个网站上缺少一部分关键信息，所以大多数人会选择从 tools.ietf.org 获取。 因为 RFC 文件实在浩如烟海（目前数量已经超过了9000！），从中找到正确的 RFC 也变成一件困难的事。显然你可以借助 Web 搜索引擎来检索，同时 RFC Editor 网站也提供了出色的站内搜索功能。 另一个选择是 EveryRFC ，在这个网站（作者搞的）允许通过 RFC 名称和关键词一起来进行搜索，以及通过标签进行探索。

RTP AAC Packet Depacketizer

由 ℡╲_俬逩灬. 提交于 2019-12-14 02:28:14
问题 I asked earlier about H264 at RTP H.264 Packet Depacketizer My question now is about the audio packets. I noticed via the RTP packets that audio frames like AAC, G.711, G.726 and others all have the Marker Bit set. I think frames are independent. am I right? My question is: Audio is small, but I know that I can have more than one frame per RTP ​​packet. Independent of how many frames I have, they are complete? Or it may be fragmented between RTP packets. 回答1: The difference between audio and

IMAP Message UID

由 余生颓废 提交于 2019-12-13 19:11:37
问题 In RFC3501 there is 2.3.1.1. Unique Identifier (UID) section: A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Most tools like Zend\Mail in PHP use the microtime, process id and uname to generate an UID for an email. So I get something like 1400603156.789.5617.imac.home,S=129:2,S . This is not conform

《邓哥奇遇记7》—— GET与POST的真正区别

由 僤鯓⒐⒋嵵緔 提交于 2019-12-13 19:03:21
　　我们会经常看到有人问：http协议中GET请求和POST请求有什么区别~？ 　　这个问题看似很简单，但是不同程度的人会回答出不同的结果。在公司的面试中，也会经常的问及类似这样的问题，看似很简单，但是不同层次的人会回答出不同的结果。那么我们今天就来聊聊HTTP协议中GET与POST的真正区别。 　　我们还是要用一句简练的话来回答GET和POST的区别： 　　提及GET和POST的区别，一定要确定基于什么前提。在不同的前提下有不同的答案。 　　这么简单的GET和POST背后有什么神秘的面纱呢？我们今天依然用邓哥的例子来讲给大家~ 　　////////// 　　邓哥家住在吃鸡村，邓嫂家住在农药屯。邓哥到邓嫂家可以有很多种选择，走着去、驾车去、坐火车去等等。邓哥通常选择驾车过去。 　　这里吃鸡村和农药屯就相当于是互联网中的两台计算机，邓哥和邓嫂相当于是这两台计算机中的两个程序，这两个程序之间想要通信可以有很多种协议，就好比有很多种交通方式可以到达。我们假设驾车这种方式就是网络中的HTTP协议。 　　邓哥家有两辆车，一辆轿车，一辆箱式货车。 　　两种车就好比是HTTP协议中的两种方式，我们假设轿车是GET请求方式，箱式货车是POST请求方式。 　　有一天邓哥想接邓嫂来吃鸡村玩，邓哥准备开箱式货车去接邓嫂。 　　邓哥要去接邓嫂，就好比程序A要向程序B发出一个请求。从原理上说
订阅 rfc