When developing HTTP client applications using SocketTools, there may be situations where it’s useful to test your code, particularly with queries to web services. We have a server available for you to test various types of requests and see what the responses are in your code.
The server test.sockettools.com supports both standard connections on port 80 and secure connections on port 443. There are several different URLs you can use to test both GET and POST requests, including support for testing XML and JSON payloads.
Basic Requests
You can use the following URL to issue a GET or POST request and the server will respond with some basic information about the request.
https://test.sockettools.com/
Because this connection will be secure, the data returned by the server will include information about the security options used, including the protocol version and cipher suite being used. You can also use a variation of this request with query parameters. For example:
https://test.sockettools.com/?param1=value2¶m2=value2
The GetData and GetFile methods in the HttpClient .NET class and ActiveX control, and the HttpGetData and HttpGetFile functions in the Library API can be used to issue GET requests.
The PostData methods in the .NET class and ActiveX control, and the HttpPostData function in the API can be used to submit data using POST requests. The PostJson and PostXml methods, and corresponding HttpPostJson and HttpPostXml functions can be used to submit requests which use JSON or XML formatted data in the payload.
XML and JSON Requests
You can submit both XML and JSON requests which will be parsed, and the output returned to your application. If the payload data is invalid (e.g.: not in the correct format), information will be returned as to why it cannot be parsed.
To submit an XML request, use the PostXml method or the HttpPostXml function using the following URL as the resource:
https://test.sockettools.com/postxml
To submit a JSON request, use the PostJson method or the HttpPostJson function using the following URL as the resource:
https://test.sockettools.com/postjson
In both cases, the XML or JSON payloads will be re-formatted using a standard structure and indentation, so the output displayed may contain additional spaces and different formatting than what you’ve submitted.
As with the other test URLs, you can append one or more query parameters and those will also be output if they are specified.
POST Form Data
Test the submission of form data to the server using the following URL with the POST method:
https://test.sockettools.com/postform
You can submit form data in a few different ways, depending on preference and the needs of the application. If the POST operation is intended to upload a file, you can use the PostFile method, or the HttpPostFile function in the API.
If you need to submit more complex form data, such as simulating a form on a website, then you can use the CreateForm method, followed by the AddField and AddFile methods as needed. When you’ve completed the form composition, you would submit it using the SubmitForm method.
For the Library API, there are the corresponding functions HttpCreateForm, HttpAddField, HttpAddFile and HttpSubmitForm.
If you want to test a file upload, you will need to specify the field name as File1 and/or File2. You can use both if you want to test uploading two files with the same request.
POST and PUT Binary Data
To submit binary data (or any other kind of data which is not the typical JSON or XML request), you can call the general purpose PostData method or HttpPostData function using the following test URL:
https://test.sockettools.com/postdata
To use the PUT command instead of POST, you can use the PutData method or the HttpPutDataEx function with this URL instead:
https://test.sockettools.com/putdata
Both will accept any type of data which is input and then output what was received in a common hex dump format, along with information about the connection and any query parameters.
News Feeds
To test the RSS API or issue a general HTTP request for XML data, there is a test news feed available:
https://test.sockettools.com/rss/
This will return a valid XML document which adheres to the RSS 2.0 standard. The test article links included in the feed are also valid and contain several paragraphs of automatically generated text. The article links in the feed will always use a secure connection by default, although this test feed can also be accessed using a standard HTTP connection.
Unicode Text
If you want to test your application to make sure it handles UTF-8 encoding correctly, you can use this document:
https://test.sockettools.com/unicode.html
This is a simple HTML document which contains messages in several different languages, including those which do not use the Latin alphabet, such as Greek, Japanese and Chinese. It also includes Hebrew and Arabic text, which are RTL (right-to-left) languages. Keep in mind that some legacy development environments, such as Visual Basic 6.0, do not fully support Unicode.
There are two common reasons this document may not display correctly for you. The first is if your project was built using a multibyte character set (ANSI) rather than Unicode. Unicode is the default for newer projects created using Visual Studio and other IDEs, however older development tools may still default to using ANSI.
Another common problem is when the components you are using to display the text do not support Unicode. For example, you will find the standard common controls in Visual Basic 6.0 will not display Unicode correctly. You may need to use third-party components for some legacy development tools.
This should not present a problem for applications developed using .NET because it uses Unicode natively and all of its components support the display of Unicode characters. Internally, SocketTools only uses Unicode to manage strings and other textual content, either as UTF-8 or UTF-16 encoded text.
When you use the Unicode version of functions in the SocketTools API, UTF-8 encoded text will automatically be converted to 16-bit Unicode characters. For more information, refer to our knowledge base article about Unicode support in SocketTools.
Debugging Payloads
For assistance with debugging the contents of a POST, PUT or PATCH payload, you can send a request which will return the data you’ve submitted using the following URL:
https://test.sockettools.com/rawdata
By default, the data returned to the client will be identical to what was submitted with the same content type. However, there are several additional modes you can use to change how the data is returned.
https://test.sockettools.com/rawdata?mode=hexdump
Using hexdump mode returns the payload data in a typical “hex dump” format where each octet (byte) of data is a hexadecimal value. This mode is useful if you are submitting binary data and you want to check to make sure the data is valid.
https://test.sockettools.com/rawdata?mode=text
Using text mode will force the data to be returned with a content type of “text/plain” regardless of the content type specified when the payload was submitted. Keep in mind this mode can result in data corruption if the payload contains binary data.
https://test.sockettools.com/rawdata?mode=binary
Using binary mode will force the data to be returned with a content type of “application/octet-stream” regardless of the content type specified when the payload was submitted.
Cookies
You can test cookies using a GET or POST request using the following URL and the server will set two cookies, SessionID and UserID.
https://test.sockettools.com/cookies
The actual cookie values are randomly generated, are limited to the test.sockettools.com domain and will expire after one day. You can include query parameters with the request which will be included in the server’s response.
Cookie values are returned in the Cookie response header. You can use the GetCookie method or the HttpGetCookie function in the API to retrieve the value of a cookie.
You can set the value of a cookie to be included with the request by calling the SetCookie method or the HttpSetCookie function and the URL above will show all cookies set for the session, along with the cookies issued with the request.
URL Redirection
You can test how your application responds to redirection with the following URL:
https://test.sockettools.com/redirect
Without any query parameters, it will redirect the request back to the test server. There are two query parameters you can include with the URL which affects how the redirection works. The first parameter is code which specifies the redirection status code. The second parameter is url which specifies the location of the redirected resource. For example:
https://test.sockettools.com/redirect?code=307&url=https://sockettools.com/
The status code must be a valid for redirection, being one of the following:
| Code | Description | |
|---|---|---|
| 301 | Moved Permanently | The resource has moved permanently, and all future requests should be made to the redirected URI. |
| 302 | Found | The resource has moved temporarily to the location specified in the response. Subsequent requests should continue to use the original URI. Most browsers have historically implemented this with the same functionality as a 303 redirection, therefore the status codes 307 and 308 were added to distinguish between the two behaviors. |
| 303 | See Other | The resource can be found using the GET method with the location URI. If this is received in response to a POST or PUT request, this indicates the server has received the data and requires the client to issue a GET request with the new resource. |
| 307 | Temporary Redirect | The resource has moved temporarily, and future requests should use the original URI. This status code works similarly to a 302 status code, however the request method cannot be changed when issuing the new request. |
| 308 | Permanent Redirect | The resource has moved permanently, and all future requests should be made using the new location URI. This is similar to the 301 status code, however the request method cannot be changed when issuing the new request. |
IPv4 and IPv6 Connections
If you connect using test.sockettools.com then SocketTools will use IPv4 by default for the connections. This is largely for compatibility, but you can choose to use IPv6 if you wish.
The HttpClient .NET class, has an option called HttpOptions.optionPreferIPv6 which can be specified when connecting to the server, either by setting the Options property or providing it when calling the Connect method.
The HttpClient ActiveX control has a similar option called httpOptionPreferIPv6 which can be assigned to the Options property or specified when calling the Connect method.
If you’re using the Library API, the HttpConnect function accepts the HTTP_OPTION_PREFER_IPV6 option. For all components, the option to prefer an IPv6 connection means SocketTools will attempt to resolve the server’s name into an IPv6 address first and will only use IPv4 if there isn’t any IPv6 record for the host.
If you want to explicitly test for just an IPv4 or IPv6 connection, there are two alternate names for the test server. The first is test-ipv4.sockettools.com and this host name will only resolve to an IPv4 address. Similarly, there is test-ipv6.sockettools.com which will only resolve to an IPv6 address and will not accept IPv4 connections.
Each of the test URLs listed above will work with either of these additional domains. For example, if you wanted to test submitting an XML request via IPv6, you could use the following:
https://test-ipv6.sockettools.com/postxml
These requests all go to the same test server, the difference is in how the DNS records are configured for each subdomain.
See Also
Testing Secure Connections with OpenSSL
Automatic URL Redirection