HTTP 多部分 (POST) 请求中的边界参数是什么？

发布于 2024-08-21 23:32:37 字数 649 浏览 6 评论 0原文

我正在尝试开发一个侧边栏小工具，该小工具可以自动检查网页以了解传输配额的变化。我快要完成了，但我还需要最后一步才能使其正常工作：将带有正确 POST 数据的 HttpRequest 发送到 php 页面。使用firefox插件，标题的“Content-Type”如下所示：

Content-Type=multipart/form-data; boundary=---------------------------99614912995

参数“boundary”似乎是随机的，POSTDATA是这样的：

POSTDATA =-----------------------------99614912995
Content-Disposition: form-data; name="SOMENAME"

Formulaire de Quota
-----------------------------99614912995
Content-Disposition: form-data; name="OTHERNAME"

SOMEDATA
-----------------------------99614912995--

我不明白如何正确模拟带有神秘的POSTDATA “边界”参数回来了。

有人知道我该如何解决这个问题吗？

原文

I am trying to develop a sidebar gadget that automates the process of checking a web page for the evolution of my transfer quota. I am almost at it but there is one last step I need to get it working: Sending an HttpRequest with the correct POST data to a php page. Using a firefox plugin, here is what the "Content-Type" of the header looks like:

Content-Type=multipart/form-data; boundary=---------------------------99614912995

with the parameter "boundary" seeming to be random, and the POSTDATA is this:

POSTDATA =-----------------------------99614912995
Content-Disposition: form-data; name="SOMENAME"

Formulaire de Quota
-----------------------------99614912995
Content-Disposition: form-data; name="OTHERNAME"

SOMEDATA
-----------------------------99614912995--

I do not understand how to correctly emulate the POSTDATA with the mystery "boundary" parameter coming back.

Would someone know how I can solve this?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

悲喜皆因你 2024-08-28 23:32:37

引用 RFC 1341，第 7.2.1 节，我认为是Content-Type 标头的 boundary 参数上的相关位（对于 MIME）：

“multipart”的所有子类型共享通用语法...
多部分实体的 Content-Type 字段需要一个参数“boundary”，用于指定封装边界。封装边界定义为完全由两个连字符（“-”，十进制代码 45）组成的行，后跟 Content-Type 标头字段中的边界参数值。

然后澄清：

因此，典型的多部分 Content-Type 标头字段可能如下所示：

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

这表明该实体由多个部分组成，每个部分本身的结构在语法上与 RFC 822 消息相同，只是标头区域可能完全为空，并且每个部分前面都有行
--gc0p4Jq0M2Yt08jU534c0p

注意事项：

封装边界必须出现在行的开头，即跟随 CRLF（回车换行）。
边界后面必须紧跟另一个 CRLF 和下一部分的标头字段，或者由两个 CRLF 组成，在这种情况下，下一部分没有标头字段（因此假定内容类型为文本/纯文本）。
封装边界不得出现在封装内，且长度不得超过 70 个字符（不包括两个前导连字符）。

最后但并非最不重要的：

最后一个主体部分后面的封装边界是一个独特的分隔符，表示后面不会再有其他主体部分。这样的分隔符与前面的分隔符相同，只是在行尾添加了两个连字符：

 --gc0p4Jq0M2Yt08jU534c0p--

我希望这对将来的其他人有帮助，因为我必须漫游一段时间才能获得完整的图片（请确保阅读必要的 RFC 以获得最深入的理解）。

To quote from the RFC 1341, section 7.2.1, what I consider to be the relevant bits on the boundary parameter of the Content-Type header (for MIME):

All subtypes of "multipart" share a common syntax ...
The Content-Type field for multipart entities requires one parameter, "boundary", which is used to specify the encapsulation boundary. The encapsulation boundary is defined as a line consisting entirely of two hyphen characters ("-", decimal code 45) followed by the boundary parameter value from the Content-Type header field.

and then clarifies:

Thus, a typical multipart Content-Type header field might look like this:

 Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

This indicates that the entity consists of several parts, each itself with a structure that is syntactically identical to an RFC 822 message, except that the header area might be completely empty, and that the parts are each preceded by the line
--gc0p4Jq0M2Yt08jU534c0p

Things to Note:

The encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF (Carriage Return-Line Feed)
The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).
Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.

Last but not least:

The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:

 --gc0p4Jq0M2Yt08jU534c0p--

I hope this helps someone else in the future, as I had to roam for a while before getting the full picture (please ensure to read the necessary RFCs to get the deepest understanding).

回复收藏 0 原文