When your application requests a resource which has moved, the server will indicate this by providing the location of the new resource URL. By default, the SocketTools HTTP client components and library will not automatically request the relocated resource, however you can enable this capability by specifying an option when the connection is made.
When you request a resource using a method such as HttpClient.GetFile or by calling the HttpGetFile function, an error is normally returned if that resource has been moved to another location. When this happens, the server will typically return either a 301 or 302 status code and will set a response header named Location which will provide the URL of the new location for the resource.
You have several choices in how your application can handle resource redirection:
- Handle it as an error condition, similar to the server reporting the resource is not found. If you expect the resource to be found at that URL and no other location, this is the appropriate action and the default behavior. This is appropriate if it’s a resource under your own direct control and you want your application to report it as an error condition if it has been moved.
- Handle the redirection in your own code after you have verified the new location. In this case, you should check the result code returned by the server after the request is made. If the server returns a code of 301 (moved permanently) or 302 (found), get the value of the Location response header. This will specify the new URL you should use to request the resource. For the components, use the GetHeader method and for the library API, use the HttpGetResponseHeader function.
- Request the SocketTools component automatically handle the redirection for you by setting the Options property to use HttpOptions.optionRedirect, or when using the library API, specify HTTP_OPTION_REDIRECT option when connecting to the server using HttpConnect.
If you chose to have SocketTools handle the redirection for you, it will automatically request the resource from the new location specified by the server. It is important to note there is no requirement for the resource to be located on the same server, or within the same domain.
Using the SocketTools Test Server
Test Secure Connections with OpenSSL