是否有通用的 HTTPS POST 冒烟测试？
调试 HTTP 客户端时，您的第一个测试可能是 Google 搜索，它可以让您查看客户端是否正确执行非 SSL GET。每个人都知道它在哪里，每个人都可以使用它，每个人都可以看到它是否成功。
我的客户在使用 HTTPS POST 时遇到问题。我可以使用专门设置的 HTTPS 服务器在本地重现它，但我希望其他人也能够尝试它。是否有使用 HTTPS 的公共网页，其中发送测试 POST 不是一个坏主意？
编辑：最后，问题是我的客户端在通过 TLS 发送时会按行缓存网络输出。显然，这会导致 POST 出现问题，但不会导致 GET 出现问题...
When debugging an HTTP client, one of your first tests is likely to be a Google search, which lets you see whether your client does non-SSL GETs properly. Everyone knows where it is, everyone can use it, and everyone can see whether it succeeded.
My client has a problem with HTTPS POST. I can reproduce it locally with my specially set-up HTTPS server, but I want others to be able to try it as well. Is there a public web page using HTTPS where sending a test POST is not a bad idea?
Edit: In the end, the problem turned out to be that my client would cache network output by the line when sending over TLS. Obviously, that causes problems for POST but not for GET...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我在寻找同样的东西时偶然发现了这个问题，但我也发现了 https://posttestserver.com/ ，为HTTP和HTTPS提供了这样的服务。
I stumbled across this question while looking for the same thing, but I also found https://posttestserver.com/, which provides such a service for HTTP and HTTPS.
Google App Engine 具有 暂时支持 HTTPS。这应该为您提供一种简单、轻松的方法来放置测试页面供任何人查看并通过 HTTP 和 HTTPS 提供它们。也给我们提供链接，如果测试足够通用，可能对我们的客户有用。
Google App Engine has supported HTTPS for a while now. That should give you a simple, easy way to put up test pages for anybody to see and serve them up over HTTP and HTTPS. Give us the link too, could be useful to use for our clients if the tests are generic enough.
我能想到的最简单的公共 HTTPS 后测试是网络邮件。
例如，创建一个虚拟 Google 帐户，然后获取该虚拟帐户的用户名和密码，并查看用户是否可以使用 https://www.google.com/accounts/ManageAccount（一个简单的 HTTPS 发布表单）。
The simplest public HTTPS post test I can think of would be webmail.
For example create a dummy Google account, then take the username and password of that dummy and see if the user can login using https://www.google.com/accounts/ManageAccount (a simple HTTPS post form).
创建一个推特帐户。由于使用了 json api，检查 Twitter 上的帖子是否有效非常简单。对于 POST，您可以查看 API 文档 状态更新。发帖后，您可以在 用户时间线。
API 文档甚至提供了简单的 curl 示例，向您展示它是多么容易。 POST：
并获取状态来检查它：
Create a twitter account. Because of the json api, checking for a valid post to twitter is very simple. For the POST, you can look at the API docs for Status Updates. Once you've made a post, you can check the results at the User Timeline.
The API docs even have simple examples with curl to show you how easy it is. The POST:
And getting the status to check it:
任何登录表单都可以。
Any login form should do.
简而言之，不。但是，如果没有关于您遇到的具体错误的进一步信息，就很难搜索已经存在的错误。我的建议是找到一个免费的托管服务，并将测试页面放在那里，并附上一个小的谷歌广告以获得一些收入。
不过，有趣的概念是公开可用的标准测试用例。我喜欢。
In short, no. But without further info as to what specific bug you're experiencing, it's hard to search for something that already exists. My suggestion would be to find a free hosting service, and put the test page up there, along with a small google ad for some revenue.
Interesting concept, though, the publicly available test cases for standards. I like.
我敢打赌，如果您以这种方式发送搜索参数，谷歌搜索将接受 POST 形式的搜索参数。
I'll bet that google search will accept a search paramter as POST if you sent it that way.
SSL 给事务增加了很多复杂性，实际上您应该将其分成两部分。
您应该首先使用 HTTPS 执行 GET。当我为 Netscape/AOL/Mozilla 进行烟雾测试网络时，我使用了 http://www.verisign.com ，因为那是主要证书供应商的主页。我没有测试 HTTP/SSL 实现本身，但我们认为，当我们坐在构建中单击链接时，我们也可以执行一些 SSL 版本的 HTTP 请求。
我很难想出一个使用 POST 的好的 https: URL，但实际上我认为它不那么重要。
一旦您知道 SSL 完全可以与 HTTP 一起工作，根据我的回忆，特定于请求的失败将非常有限。话又说回来，这个区域并不是直接分配给我的，所以对此持保留态度。
我最近关于测试的想法是测试组需要设置他们的系统，特别是测试服务器。通过获得一组关于如何使用自签名证书配置 HTTPS 的良好工作说明，然后创建您自己的内部 POST 测试页面，您可能会获得更好的效果。
SSL adds a lot of complexity to the transaction, and you actually should break it up into two pieces.
You should do an GET w/ HTTPS first. When I was smoke testing networking for Netscape/AOL/Mozilla, I used http://www.verisign.com, because that was the home page for the main certificate vendor. I did not test the HTTP/SSL implementation itself, but we figured that while we are sitting around clicking on links in a build, we may as well do some SSL versions of the HTTP requests.
I cannot easily think of a good https: URL that uses POST, but I actually think it matters a lot less.
Once you know that SSL is working w/ HTTP at all, failures that are request-specific are going to be pretty limited, based on my recollection. Then again, this area was not assigned directly to me, so take that with a grain of salt.
My more recent thinking about testing is that test groups need to setup their systems, especially test servers. You would probably get better mileage by getting a good working set of instructions on how to configure HTTPS w/ a self signed certs, and then create your own internal POST test pages.