views:

647

answers:

7

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...

+4  A: 

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).

David
+1  A: 

Any login form should do.

Josh Stodola
A: 

I'll bet that google search will accept a search paramter as POST if you sent it that way.

Joshua
+1  A: 

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.

SEK
+3  A: 

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:

curl -u user:password -d "status=testing my HTTP POST request" https://twitter.com/statuses/update.json

And getting the status to check it:

curl https://twitter.com/statuses/user_timeline.json?screen_name=user
Douglas Mayle
A: 

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.

benc
+4  A: 

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.

slf
Accepted for best long-term solution. I didn't think about that :)
legoscia