- 浏览: 115508 次
- 性别:
- 来自: 北京
最新评论
-
ksfsb0345299:
com.sinoufc.base.monitor.item.m ...
读MIB文件 -
di1984HIT:
学习了~~~
读MIB文件 -
diyunpeng:
文章写的不错
WMI常见问题及解决方法 -
lnfszl:
...
JMX监控tomcat
1.数据发送形式
使用POST请求,数据在请求体(REQUEST HEADER)中传递给服务器。使用GET请求,数据将编码到URL中。
注意:POST请求的URL也可是http://www.example.com/index.php?a=hello&b=world的形式,只是其发送的数据将在请求体中。GET请求会把发送的数据编码后加在URL后,无论此前URL长什么样子。
2.什么时候使用GET和POST
GET 适用于多数请求,而POST 仅用于更新站点。根据 HTTP 规范,GET 用于信息获取,而且应该是幂等的。也就是说,当使用相同的URL重复GET请求会返回预期的相同结果时,GET方法才是适用的。当对一个请求有副作用的时候(例如,提交数据注册新用户时),应该使用POST请求而不是GET。[参考2]
3.URL长度问题
RFC 2616、 " 超文本传输协议 -- HTTP /1.1, " 未指定任何对 URL 长度要求。
Microsoft Internet Explorer 具有统一资源定位器 (URL) 长度的 2,083 字符。 InternetExplorer 也有路径长度为 2,048 字符。如果使用 GET 方法, 您仅限于最多 2,048 字符, 减去实际路径中的字符数。[参考3]。网上流传256,1k等长度URL限制,可能对于以前古老的浏览器,现在应该纠正了,大概上对于IE是2k。
URL长度限制适用于 POST 请求和 GET 请求 URL。
对使用GET方法提交数据时,在IE环境下,需要注意其数据编码加到URL后其长度受到2083字节的限制。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持。POST提交数据大小理论没有限制,HTTP协议规范也没有进行大小限制。“POST数据量存在128K的大小限制”不够准确,POST数据是没有限制的,起限制作用的是服务器的处理程序的处理能力[参考1]。
4.GET请求的安全性
对于GET请求,其数据将附加在URL中,在浏览器地址栏中会显示出来。在用户登录时,其用户名和密码等信息将显示在浏览器地址栏中,若登录页面被浏览器缓存或者被浏览器历史记录则其他用户可以通过此机器拿到用户信息。而对于网络传输数据层面来讲,GET和POST安全性是没有太大区别的。
GET请求发送数据时,其数据是需要进行URL编码的,一些字符会发生改变,在服务端接受时需要做URL解码处理。对于某些WEB服务器,其GET请求会记录在服务器上,如果里面含有隐私数据将有可能被第三方获取[参考5]。
附件一:
[参考6]
HTTP协议中GET方法和POST方法是有所不同的,RFC1945中的英文原文如下:
8.1 GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
The semantics of the GET method changes to a "conditional GET" if the
request message includes an If-Modified-Since header field. A
conditional GET method requests that the identified resource be
transferred only if it has been modified since the date given by the
If-Modified-Since header, as described in Section 10.9. The
conditional GET method is intended to reduce network usage by
allowing cached entities to be refreshed without requiring multiple
requests or transferring unnecessary data.
8.3 POST
The POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the
resource identified by the Request-URI in the Request-Line. POST is
designed to allow a uniform method to cover the following functions:
o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
o Providing a block of data, such as the result of submitting a
form [3], to a data-handling process;
o Extending a database through an append operation.
The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity
is subordinate to that URI in the same way that a file is subordinate
to a directory containing it, a news article is subordinate to a
newsgroup to which it is posted, or a record is subordinate to a
database.
A successful POST does not require that the entity be created as a
resource on the origin server or made accessible for future
reference. That is, the action performed by the POST method might not
result in a resource that can be identified by a URI. In this case,
either 200 (ok) or 204 (no content) is the appropriate response
status, depending on whether or not the response includes an entity
that describes the result.
If a resource has been created on the origin server, the response
should be 201 (created) and contain an entity (preferably of type
"text/html") which describes the status of the request and refers to
the new resource.
A valid Content-Length is required on all HTTP/1.0 POST requests. An
HTTP/1.0 server should respond with a 400 (bad request) message if it
cannot determine the length of the request message's content.
Applications must not cache responses to a POST request because the
application has no way of knowing that the server would return an
equivalent response on some future request.
翻译成中文(黄晓东翻译,xdhuang@eyou.com)就是
8.1 GET
GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一
个数据产生过程,那么最终要在回应实体中返回的是由该处理过程的结果所指向
的资源,而不是返回该处理过程的描述文字,除非那段文字恰好是处理的输出。
如果请求消息包含If-Modified-Since标题域,GET方法的语法就变成“条件GET”,
即“(conditional GET)”。 条件GET方法可以对指定资源进行判断,如果它在
If-Modified-Since标题域(见10.9节)中的指定日期后发生了更新,才启动传
输,否则不传输。这种条件GET允许被缓存的实体在不必经过多次请求或不必要
的数据传输就能进行刷新,从而有助于降低网络负载。
8.3 POST
POST方法用来向目的服务器发出请求,要求它接受被附在请求后的实体,并把它
当作请求队列(Request-Line)中请求URI所指定资源的附加新子项。POST被设计
成用统一的方法实现下列功能:
o 对现有资源的注释(Annotation of existing resources);
o 向电子公告栏、新闻组,邮件列表或类似讨论组发送消息;
o 提交数据块,如将表格(form [3])的结果提交给数据处理过程;
o 通过附加操作来扩展数据库。
POST方法的实际功能由服务器来决定,而且通常依赖于请求URI。在POST过程中,
实体是URI的从属部分,就好象文件从属于包含它的目录、新闻组文件从属于发出
该文件的新闻组、记录从属于其所在的数据库一样。
成功的POST不需要在原始服务器创建实体,并将其做为资源;也不需要为未来的
访问提供条件。也就是说,POST方法不一定会指向URI指定的资源。在这种情况下,
200(成功)或204(无内容)都是适当的回应状态,取决于实际回应实体中对结
果的描述。
如果在原始服务器上创建了资源,回应应是201(已创建),并包含一个实体
(对"text/html"类型最为适合),该实体中记录着对新资源请求的状态描述。
在所有的HTTP/1.0的POST请求中,必须指定合法的内容长度(Content-Length)。
如果HTTP/1.0服务器在接收到请求消息内容时无法确定其长度,就会返回400(非
法请求)代码。
应用程序不能缓存对POST请求的回应,因为做为应用程序来说,它们没有办法知道
服务器在未来的请求中将如何回应。
附件二:
WWW FAQs: What is the maximum length of a URL?
[参考4]
2006-10-13: Although the specification of the HTTP protocol does not specify any maximum length, practical limits are imposed by web browser and server software.
Microsoft Internet Explorer (Browser)
Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.
Firefox (Browser)
After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.
Safari (Browser)
At least 80,000 characters will work. I stopped testing after 80,000 characters.
Opera (Browser)
At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.
Apache (Server)
My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.
Microsoft Internet Information Server
The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
Recommendations
Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users.
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
<form action="myscript.php" method="POST">
...
</form>
The form fields are then transmitted as part of the HTTP transaction header, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL.
The Bookmark Problem
In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
"What happens if the URL is too long for the server?"
What exactly happens if a browser that supports very long URLs (such as Firefox) submits a long URL to a web server that does not support very long URLs (such as a standard build of Apache)?
The answer: nothing dramatic. Apache responds with a "413 Entity Too Large" error, and the request fails.
This response is preferable to cutting the URL short, because the results of cutting the URL short are unpredictable. What would that mean to the web application? It varies. So it's better for the request to fail.
In the bad old days, some web servers and web browsers failed to truncate or ignore long URLs, resulting in dangerous "buffer overflow" situations. These could be used to insert executable code where it didn't belong... resulting in a security hole that could be exploited to do bad things.
These days, the major browsers and servers are secure against such obvious attacks - although more subtle security flaws are often discovered (and, usually, promptly fixed).
While it's true that modern servers are themselves well-secured against long URLs, there are still badly written CGI programs out there. Those who write CGI programs in C and other low-level languages must take responsibility for paying close attention to potential buffer overflows. The CGIC library can help with this.
In any case, if you're a web developer and you're still asking this question, then you probably haven't paid attention to my advice about how to avoid the problem completely.
参考文献:
[1] 表单Post&Get两个长度限制问题的分析[N] http://phoubes.bokee.com/5488853.html
[2] David Flanagan. Javascript权威指南【第五版】[m].北京:机械工业出版社,2007.8
[3] Maximum URL length is 2,083 characters in Internet Explorer[N] http://support.microsoft.com/kb/q208427/
[4] WWW FAQs: What is the maximum length of a URL? [N] http://www.boutell.com/newfaq/misc/urllength.html
[5] HTTP/1.1: Method Definitions[N] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
[6] HTTP协议中的GET和POST[N] http://www.cnblogs.com/westsourcer/archive/2008/06/12/702521.html
使用POST请求,数据在请求体(REQUEST HEADER)中传递给服务器。使用GET请求,数据将编码到URL中。
注意:POST请求的URL也可是http://www.example.com/index.php?a=hello&b=world的形式,只是其发送的数据将在请求体中。GET请求会把发送的数据编码后加在URL后,无论此前URL长什么样子。
2.什么时候使用GET和POST
GET 适用于多数请求,而POST 仅用于更新站点。根据 HTTP 规范,GET 用于信息获取,而且应该是幂等的。也就是说,当使用相同的URL重复GET请求会返回预期的相同结果时,GET方法才是适用的。当对一个请求有副作用的时候(例如,提交数据注册新用户时),应该使用POST请求而不是GET。[参考2]
3.URL长度问题
RFC 2616、 " 超文本传输协议 -- HTTP /1.1, " 未指定任何对 URL 长度要求。
Microsoft Internet Explorer 具有统一资源定位器 (URL) 长度的 2,083 字符。 InternetExplorer 也有路径长度为 2,048 字符。如果使用 GET 方法, 您仅限于最多 2,048 字符, 减去实际路径中的字符数。[参考3]。网上流传256,1k等长度URL限制,可能对于以前古老的浏览器,现在应该纠正了,大概上对于IE是2k。
URL长度限制适用于 POST 请求和 GET 请求 URL。
对使用GET方法提交数据时,在IE环境下,需要注意其数据编码加到URL后其长度受到2083字节的限制。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持。POST提交数据大小理论没有限制,HTTP协议规范也没有进行大小限制。“POST数据量存在128K的大小限制”不够准确,POST数据是没有限制的,起限制作用的是服务器的处理程序的处理能力[参考1]。
4.GET请求的安全性
对于GET请求,其数据将附加在URL中,在浏览器地址栏中会显示出来。在用户登录时,其用户名和密码等信息将显示在浏览器地址栏中,若登录页面被浏览器缓存或者被浏览器历史记录则其他用户可以通过此机器拿到用户信息。而对于网络传输数据层面来讲,GET和POST安全性是没有太大区别的。
GET请求发送数据时,其数据是需要进行URL编码的,一些字符会发生改变,在服务端接受时需要做URL解码处理。对于某些WEB服务器,其GET请求会记录在服务器上,如果里面含有隐私数据将有可能被第三方获取[参考5]。
附件一:
[参考6]
HTTP协议中GET方法和POST方法是有所不同的,RFC1945中的英文原文如下:
8.1 GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
The semantics of the GET method changes to a "conditional GET" if the
request message includes an If-Modified-Since header field. A
conditional GET method requests that the identified resource be
transferred only if it has been modified since the date given by the
If-Modified-Since header, as described in Section 10.9. The
conditional GET method is intended to reduce network usage by
allowing cached entities to be refreshed without requiring multiple
requests or transferring unnecessary data.
8.3 POST
The POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the
resource identified by the Request-URI in the Request-Line. POST is
designed to allow a uniform method to cover the following functions:
o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
o Providing a block of data, such as the result of submitting a
form [3], to a data-handling process;
o Extending a database through an append operation.
The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity
is subordinate to that URI in the same way that a file is subordinate
to a directory containing it, a news article is subordinate to a
newsgroup to which it is posted, or a record is subordinate to a
database.
A successful POST does not require that the entity be created as a
resource on the origin server or made accessible for future
reference. That is, the action performed by the POST method might not
result in a resource that can be identified by a URI. In this case,
either 200 (ok) or 204 (no content) is the appropriate response
status, depending on whether or not the response includes an entity
that describes the result.
If a resource has been created on the origin server, the response
should be 201 (created) and contain an entity (preferably of type
"text/html") which describes the status of the request and refers to
the new resource.
A valid Content-Length is required on all HTTP/1.0 POST requests. An
HTTP/1.0 server should respond with a 400 (bad request) message if it
cannot determine the length of the request message's content.
Applications must not cache responses to a POST request because the
application has no way of knowing that the server would return an
equivalent response on some future request.
翻译成中文(黄晓东翻译,xdhuang@eyou.com)就是
8.1 GET
GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一
个数据产生过程,那么最终要在回应实体中返回的是由该处理过程的结果所指向
的资源,而不是返回该处理过程的描述文字,除非那段文字恰好是处理的输出。
如果请求消息包含If-Modified-Since标题域,GET方法的语法就变成“条件GET”,
即“(conditional GET)”。 条件GET方法可以对指定资源进行判断,如果它在
If-Modified-Since标题域(见10.9节)中的指定日期后发生了更新,才启动传
输,否则不传输。这种条件GET允许被缓存的实体在不必经过多次请求或不必要
的数据传输就能进行刷新,从而有助于降低网络负载。
8.3 POST
POST方法用来向目的服务器发出请求,要求它接受被附在请求后的实体,并把它
当作请求队列(Request-Line)中请求URI所指定资源的附加新子项。POST被设计
成用统一的方法实现下列功能:
o 对现有资源的注释(Annotation of existing resources);
o 向电子公告栏、新闻组,邮件列表或类似讨论组发送消息;
o 提交数据块,如将表格(form [3])的结果提交给数据处理过程;
o 通过附加操作来扩展数据库。
POST方法的实际功能由服务器来决定,而且通常依赖于请求URI。在POST过程中,
实体是URI的从属部分,就好象文件从属于包含它的目录、新闻组文件从属于发出
该文件的新闻组、记录从属于其所在的数据库一样。
成功的POST不需要在原始服务器创建实体,并将其做为资源;也不需要为未来的
访问提供条件。也就是说,POST方法不一定会指向URI指定的资源。在这种情况下,
200(成功)或204(无内容)都是适当的回应状态,取决于实际回应实体中对结
果的描述。
如果在原始服务器上创建了资源,回应应是201(已创建),并包含一个实体
(对"text/html"类型最为适合),该实体中记录着对新资源请求的状态描述。
在所有的HTTP/1.0的POST请求中,必须指定合法的内容长度(Content-Length)。
如果HTTP/1.0服务器在接收到请求消息内容时无法确定其长度,就会返回400(非
法请求)代码。
应用程序不能缓存对POST请求的回应,因为做为应用程序来说,它们没有办法知道
服务器在未来的请求中将如何回应。
附件二:
WWW FAQs: What is the maximum length of a URL?
[参考4]
2006-10-13: Although the specification of the HTTP protocol does not specify any maximum length, practical limits are imposed by web browser and server software.
Microsoft Internet Explorer (Browser)
Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.
Firefox (Browser)
After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.
Safari (Browser)
At least 80,000 characters will work. I stopped testing after 80,000 characters.
Opera (Browser)
At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.
Apache (Server)
My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.
Microsoft Internet Information Server
The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
Recommendations
Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users.
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
<form action="myscript.php" method="POST">
...
</form>
The form fields are then transmitted as part of the HTTP transaction header, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL.
The Bookmark Problem
In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
"What happens if the URL is too long for the server?"
What exactly happens if a browser that supports very long URLs (such as Firefox) submits a long URL to a web server that does not support very long URLs (such as a standard build of Apache)?
The answer: nothing dramatic. Apache responds with a "413 Entity Too Large" error, and the request fails.
This response is preferable to cutting the URL short, because the results of cutting the URL short are unpredictable. What would that mean to the web application? It varies. So it's better for the request to fail.
In the bad old days, some web servers and web browsers failed to truncate or ignore long URLs, resulting in dangerous "buffer overflow" situations. These could be used to insert executable code where it didn't belong... resulting in a security hole that could be exploited to do bad things.
These days, the major browsers and servers are secure against such obvious attacks - although more subtle security flaws are often discovered (and, usually, promptly fixed).
While it's true that modern servers are themselves well-secured against long URLs, there are still badly written CGI programs out there. Those who write CGI programs in C and other low-level languages must take responsibility for paying close attention to potential buffer overflows. The CGIC library can help with this.
In any case, if you're a web developer and you're still asking this question, then you probably haven't paid attention to my advice about how to avoid the problem completely.
参考文献:
[1] 表单Post&Get两个长度限制问题的分析[N] http://phoubes.bokee.com/5488853.html
[2] David Flanagan. Javascript权威指南【第五版】[m].北京:机械工业出版社,2007.8
[3] Maximum URL length is 2,083 characters in Internet Explorer[N] http://support.microsoft.com/kb/q208427/
[4] WWW FAQs: What is the maximum length of a URL? [N] http://www.boutell.com/newfaq/misc/urllength.html
[5] HTTP/1.1: Method Definitions[N] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
[6] HTTP协议中的GET和POST[N] http://www.cnblogs.com/westsourcer/archive/2008/06/12/702521.html
发表评论
-
Properties配置文件修改后重读的功能
2011-11-29 10:35 1347import java.io.File; import ja ... -
SocketClient
2011-11-25 11:03 2038package com.sinoufc.base.moni ... -
Timer
2011-11-25 10:59 866import java.util.Timer; pu ... -
jinterop获取windows事件三类日志(Security、Application、System)
2011-11-25 10:57 6599package com.mytest; import ... -
EditPlus配置Java编译环境
2011-10-19 13:35 1089从菜单“工具 (Tools)”;“配置用户工具...”进入用 ... -
关于VO、PO的理解-java的(PO,VO,TO,BO,DAO,POJO)解释(转)
2011-10-08 17:35 887O/R Mapping 是 Object Relational ... -
java调用url的两种方式
2011-06-14 17:27 13928一、在java中调用url,并打开一个新的窗口 Strin ... -
MSSQLSERVER-MIB.mib读不出数据或JAVA解析错误纠正
2011-03-07 16:57 1254从官网上下的sqlserver MIB文件,也从安装目录弄的这 ... -
遍历MAP
2011-02-25 13:20 1026//JDK1.5 Map map = new HashMa ... -
求交差集
2011-02-25 13:13 967String s1 = "50000,10000 ... -
java播放声音文件
2011-02-21 16:17 1240支持.au声音文件,其它的格式没试过。 package ... -
java发送邮件代码
2011-02-21 09:23 963转:http://cqjc.iteye.com/blog/27 ... -
url传中文和中文传到JS乱码问题
2011-02-09 10:39 8281.url传中文 js:encodeURI(name) //编 ... -
查找不连续数字字符串
2011-02-09 10:24 1791对己经排好序的数字字符串,查找出不连续的。 public ... -
配置文件修改后重读的功能
2011-01-18 15:07 1171import java.io.File; import ... -
设置jdk环境变量
2011-01-13 15:04 1098电脑属性->高级->环境变量->系统变量 ... -
产生不重复随机数
2011-01-13 14:53 1068import java.util.*; public c ... -
日期操作类
2011-01-13 11:52 855import java.text.ParseExcepti ... -
File操作类
2011-01-13 11:51 995import java.io.BufferedReader ... -
读MIB文件
2011-01-13 11:45 7213import java.io.File; import ...
相关推荐
Django 中request.get和request.post的区别 POST和GET差异: POST和GET是HTTP协议定义的与服务器交互的方法。GET一般用于获取/查询资源信息,而POST一般用于更新资源信息。另外,还有PUT和DELETE方法。 POST和GET都...
二、 Ajax 中 Get 和 Post 的区别 1. Get 方式:使用 get 方式可传送简单数据,但大小一般限制在 1KB 下,数据追加到 url 中发送(http 的 header 传送)。另外,get 方式会被客户端的浏览器缓存起来,这可能会带来...
GET请求和POST请求详解 GET请求和POST请求是HTTP协议中的两种基本请求方式,它们的使用场景和实现机制有着本质的区别。在本文中,我们将详细介绍GET请求和POST请求的区别、使用场景和安全性。 1. GET请求和POST...
### AJAX POST 与 GET 提交的区别详解 #### 一、GET与POST基本概念及应用场景 在探讨AJAX中GET和POST的区别之前,我们先来了解一下这两种请求方式的基本概念。 **GET**请求通常用于获取资源信息,它将参数拼接到...
HTTP中GET和POST的区别详解 HTTP协议中有多种方法,如GET、POST、PUT、DELETE等,每种方法都有其特点和用途。今天,我们将详细介绍HTTP中GET和POST的区别,了解它们的原理和应用场景。 GET方法 根据HTTP规范,GET...
"PHP 中 $_GET 和 $_POST 方法详解" 一、 $_GET 数组 * 在 PHP 中,$_GET 数组用于接收 GET 请求的数据 * GET 请求是 HTTP 中最原始的请求方式,通过点击超链接或在地址栏输入 URL 都会发送一个 GET 请求 * 在 GET...
GET 和 POST 是我们最常用的两种请求方式,今天讲一讲如何在 golang 服务中,正确接收这两种请求的参数信息。 处理GET请求 1.1 接收GET请求 //接收GET请求 func Get(writer http.ResponseWriter , request *...
详解http的put delete get post
### GET请求和POST请求的区别详解 #### 一、概述 HTTP协议定义了多种与服务器进行交互的方法,其中最基本的包括GET、POST、PUT和DELETE。这些方法分别对应于对网络资源的查询、更新、创建和删除操作。GET通常用于...
本资源是一个封装类,采用异步方式解决了Wininet不能设置超时的问题,当前异步采用C++...MFC程序中通过HttpGet和HttpPost方式向WebService发送请求,WebService以Json的方式返回数据,MFC程序解析Json,得到指定数据。
这个压缩包可能包含了实现HTTP GET和POST请求所需的jar包以及示例代码,帮助开发者理解如何使用HttpClient进行网络通信。下面将详细介绍HttpClient库,HTTP请求的基本概念,以及GET和POST方法的差异。 HttpClient是...
GET和POST作为HTTP协议中最基本也是最重要的两种请求方式,在实际开发过程中有着广泛的应用。GET方法适用于获取数据,而POST方法则更多用于发送数据,两者各有特点和适用场景。开发者需要根据实际需求选择合适的方法...
本文主要解析jQuery中的$.get()、$.post()等方法,以及相关的$.getScript()和$.getJSON()方法。 首先,$.get()方法是使用HTTP GET请求方式向服务器获取数据。其基本语法如下: ```javascript $.get(url, data, ...
在Web开发中,特别是使用JSP(Java Server Pages)进行服务器端编程时,经常需要通过HTTP客户端库(如HttpClient)来发起网络请求,包括GET和POST请求。其中,POST请求通常用于向服务器提交数据,例如用户表单数据的...
本文主要解析jQuery中的$.get()、$.post()等Ajax方法,以及相关的$.getScript()和$.getJSON()方法。 首先,$.get()方法是使用GET方式发送异步请求,基本语法如下: ```javascript $.get(url, data, callback, type...
### 知识点详解:JSP页面中文参数传递GET与POST方法分析 #### 一、引言 在Java Web开发中,特别是在处理JSP页面时,中文参数的正确传递是常见的需求之一。不当的处理可能导致乱码问题,严重影响用户体验和数据的...
通过添加对应的jar包依赖,我们可以轻松地在Java项目中发送GET和POST请求。上述代码示例和注解解释有助于理解HttpClient的工作原理和使用方法。在实际开发中,根据具体需求,可能还需要处理如超时、重试、cookie等更...