Doesn't WWW like HTTP 302 (Redirect)?

Hello!

Below is a very simple REST class around the WWW object.
It sends a HTTP request, calls the callback when necessary and protects it in case of bad request.
The actual class is slightly more complicated :wink:

public delegate void RequestCallback (WWW request);
public delegate void DataCallback (string text);
public class REST : MonoBehaviour
{
    public DataCallback MakeRequestCallback(APICallback callback)
    {
        return (request) => 
        {
            if( !string.IsNullOrEmpty( request.error ) ) 
            {
                Debug.LogError( "Error during request: " + request.error );
            }
            else if( c!=null ) 
            {
                callback(request.text);
            }
        };
    }
    public IEnumerator MakeRequest (string url, RequestCallback callback)
    {
        WWW request = new WWW(url);
        return WaitForRequest(request, callback);
    }
}

When I want to fetch data, I can do something like this (from inside a MonoBehaviour):

// REST rest is accessed on the Awake() of the MonoBehaviour
// doSomething could be print or Debug.LogError
string url = "http://mydomain.com/myscript.php";
RequestCallback callback = rest.MakeRequestCallback( doSomething ); 
StartCoroutine(rest.MakeRequest(url, callback));

Now all this works fine, unless the script on the server does something funky like a HTTP 302 redirection (which translates in PHP as header(“Location: path”); )

Let’s say for example that I have static ASCII data files and a PHP script to pick one randomly. The most natural way would be to redirect to that random file.

If I do that, the following message appears in my console:

“Error during request: unsupported url”

It could be the extension of the file that makes it an ugly URL. But I don’t think so: I printed the “unsupported” URL in the console from the if-block of “Error during request” and it was exactly the path to my PHP script.

I solved my problem by dumping the contents of the chosen file into the return of the script, but I feel it’s not as scalable as a redirection would have been. And not a good practice in general (some of the files can be lengthy).

I haven’t tried to access the file directly from a WWW request yet, I will do and update this post, however I found no reference on “unsupported URLs” or redirect headers with WWW, so I thought it would be good to share.
As I use iOS, I cannot use the other framework WebRequest/HTTPRequest.

Is it a bug? Is it the expected behavior?

Thanks,
Antho

The www class implements only a simple http request. It just wraps a normal tcp socket, nothing more. All it can do is send the request to the server and it waits for the response. Like the http status codes explains only status codes that start with 2xx are “success”. A redirection is a case where the client / user “must take additional action to complete the request”. The client have to do a new seperate request to get the actual file.

Unfortunately the WWW class doesn’t provide the status code so you can’t check it yourself. What you can do is check the (still undocumented) .responseHeaders for a “location” header field and preform another get request.

( I guess you use visual studio so you shouldn’t have problems to use responseHeaders :wink: )

Alternatively, scrub WWW altogether and use UniWeb. You can do anything HTTP related with it.