none
Windows Phone 8 BackgroundFileTransfer can't handle HTTP code 301? Answer: WP8 can't handle HTTPS connections.

    Question



  • I am using the BackgroundFileTransfer method to download large audio files on Windows Phone. Everything works great on Windows Phone 7, but on Windows Phone 8 it seems I get TransferError = "The HTTP network provider returned an error" for some files and I see the status code being 301 (Moved permanently).

    I also get SystemException if I try to open this URL in the BackgroundAudioPlayer (which also works on WP7).

    So doesn't WP8 know how to handle HTTP code 301?




    • Edited by Johan Paul Saturday, January 05, 2013 12:44 PM Put the answer to the title.
    Friday, January 04, 2013 3:50 PM

Answers

  • I did some more investigation and I have some more info. Let's cut to the chase; it's not related to HTTP 301 at all but HTTPS connection. Both of the URLs that do not work are behind HTTPS.

    Please see attached images. WP8 doesn't even try to fetch anything as it send "FIN, ACK" after the handshake. WP8 just gives up. WP7 on the other hand sends "SYN" as it should and starts to download the file (after receiving HTTP 301).

    Microsoft, is this is a known issue in WP8 and will it be fixed soon?



    • Marked as answer by Johan Paul Saturday, January 05, 2013 12:43 PM
    • Edited by Johan Paul Saturday, January 05, 2013 12:47 PM
    Saturday, January 05, 2013 12:43 PM
  • Hi Johan,

    This appears to be the same issue as reported in the following forum post:

    http://social.msdn.microsoft.com/Forums/en-US/wpdevelop/thread/db3d70c1-a013-4bb8-bf88-39cd9a9bca63

    This was recorded into our issues database; it is currently marked as investigate.

    It appears that eschumac is likely correct in that the root cause is the redirect from HTTPS to HTTP is canceled for security reasons.

    It appears that content from other servers via HTTPS seems to work so this seems to be an issue specific to SoundCloud.

    I recommend that for now, you implement a workaround if possible; such as using HTTP instead of HTTPS, alternately you could play back content from this server by handling the redirect yourself in app code:

    public MainPage()
    {
        InitializeComponent();
    
        PlaySoundCloudTrack("https://api.soundcloud.com/tracks/66214123/stream?client_id=f17e6e71bb879390a264eef8b689a655");
    }
    
    private void PlaySoundCloudTrack(string trackUri)
    {
        HttpWebRequest req = HttpWebRequest.CreateHttp(trackUri);
        req.BeginGetResponse((result) =>
        {
            HttpWebResponse res = req.EndGetResponse(result) as HttpWebResponse;
            Dispatcher.BeginInvoke(() => myMediaElement.Source = res.ResponseUri);
        }, null);
    }

    Hope this helps,
    Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8



    Monday, January 07, 2013 3:30 PM

All replies

  • Hi,

    When failing, is your app a 7.1 application running in a Windows Phone 8 device? If yes, it might be something to do with your new phone or its network setup, such as the performance capability of the network connection.

    -Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8

    Friday, January 04, 2013 5:13 PM
  • I am running this in the WP8 emulator which is connected to a fast LAN. But I also got the same feedback from a user of my app with a WP8 device.
    Friday, January 04, 2013 5:36 PM
  • I would also like to add that this doesn't happen to all URLs that return 301, but I have two that I can reproduce the issue 100% with. I can email the information if needed.
    Friday, January 04, 2013 5:37 PM
  • Have you tried checking out the traffic in something like Fiddler?
    Friday, January 04, 2013 7:34 PM
  • What would I be looking for? I looked at the HTTP headers with "curl -IL" and they are fine, the files download with curl, Firefox and WP7. Not with WP8.
    Friday, January 04, 2013 7:35 PM
  • I'd personally look at the traffic flow differences between the platforms and compare the sessions to look for deltas. Any number of things could be different. It could allow you to fiddle with the traffic and spoof the WP8 on the desktop to narrow down the potential issue.
    Friday, January 04, 2013 7:48 PM
  • Well - the problem is that there's no much I can do with regards to how the platform handles the URL and the HTTP traffic. I give the BackgroundFileTransfer request a URL and start it. But there's nothing more I can do.

    If not - of course - I am overseeing some API option that WP8 needs compared to WP7. That's maybe the thing I am after for. Or if this is in fact a bug in WP8, I hope Microsoft can make a bug report from this and have the issue fixed.

    Friday, January 04, 2013 7:51 PM
  • I understand what you are saying, but can you answer that the post/response traffic is exactly the same on WP7 and WP8 up to the point at which WP8 code stops working? Just trying to move the ball forward.
    Friday, January 04, 2013 10:00 PM
  • Thanks, I see. I will do some more investigating over the weekend and post here some more info.

    In the meantime, if Microsoft is interested in doing some research of their own for the URLs, I would love to send the information about the URLs that I can get WP8 to crash to someone.

    Friday, January 04, 2013 11:01 PM
  • I did some more investigation and I have some more info. Let's cut to the chase; it's not related to HTTP 301 at all but HTTPS connection. Both of the URLs that do not work are behind HTTPS.

    Please see attached images. WP8 doesn't even try to fetch anything as it send "FIN, ACK" after the handshake. WP8 just gives up. WP7 on the other hand sends "SYN" as it should and starts to download the file (after receiving HTTP 301).

    Microsoft, is this is a known issue in WP8 and will it be fixed soon?



    • Marked as answer by Johan Paul Saturday, January 05, 2013 12:43 PM
    • Edited by Johan Paul Saturday, January 05, 2013 12:47 PM
    Saturday, January 05, 2013 12:43 PM
  • The phone supports SSL.

    What is the size of this file?

    Are you using any network simulation when you are trying this?

    What's the root cert and ssl being used?

    Saturday, January 05, 2013 3:09 PM
  • I know the phone supports HTTPS in the browser at least, but with these APIs I am showing differently. The file is 32MB in size.

    I am not using any simulation.

    The root cert is whatever the WP8 emulator has. I am not doing anything on my own - just using the emulator and catching the traffic. The evidence is there: WP8 disconnects the session, while WP7 doesn't.



    • Edited by Johan Paul Saturday, January 05, 2013 3:31 PM
    Saturday, January 05, 2013 3:26 PM
  • This is the file. https://soundcloud.com/fypfanzine/fyp-christmas-day-podcast-2012/download.mp3
    Saturday, January 05, 2013 3:26 PM
  • Its doing a redirect to an HTTP endpoint.
    Saturday, January 05, 2013 4:24 PM
  • Who? Where? Wireshark's network capture doesn't show any HTTP traffic when interacting with the WP8 device.

    Please point out in the network capture this.

    Saturday, January 05, 2013 4:26 PM
  • It is evident in the traffic in your first screenshot.

    I vaguely remember reading a post here a little while ago that WP8 didn't like that scenario.



    Saturday, January 05, 2013 4:50 PM
  • Try it in the browser. Use that url to download. Lets say use Firefox. Go to your download and right click and copy the download link. Compare the two.

    http://ec-media.soundcloud.com/NL0tgkRDsHkk?ff61182e3c2ecefa438cd0210ad0e38569b9775ddc9e06b3c362a6833c935beb719844dd1f9040d8fb51643a1baeec6e828469ce769b1919623cb75a53&AWSAccessKeyId=AKIAJ4IAZE5EOI7PA7VQ&Expires=1357402996&Signature=DdEQtiyY%2FAwgEj4zK4a4lwQ0Ra8%3D

    Saturday, January 05, 2013 4:51 PM
  • A desktop browser has nothing to do with this scenario.

    Of course I know it redirects to a HTTP endpoint. I have downloaded the file more than twice. I don't know what it has to do anything with anything at this point when I try to explain to you that the first HTTPS endpoint doesn't work in WP8.

    Saturday, January 05, 2013 4:53 PM
  • Yes, it does a HTTP 301 redirect if the HTTPS connection is established. With WP8 this is not the case.

    You mean WP8 not liking HTTPS endpoints with these APIs?

    Saturday, January 05, 2013 4:55 PM
  • I can tell you are getting frustrated, but it's a little hard to do these kinds of things in a discussion thread without all the data. It's not possible for me to read your wireshark output.

    I didn't code this up and run it on the emulator. I just dont have the time so I'm suggesting things for you to look at. Its not always possible to write a lot of info. Just trying to help.

    What I am suggesting is that you can look into this redirect behavior and how the code may or may not be handling it...automagically. It very well may be that you need to make a request to get the actual download url and then use that in your code to get the file. Obviously, the actual endpoint for the file you are trying to get is not SSL. So this may actually not be an ssl issue at all. It might be an issue of how the redirect is happening.


    • Edited by eschumac Saturday, January 05, 2013 5:07 PM always some spelling mistakes
    Saturday, January 05, 2013 4:59 PM
  • No, I mean WP8 not liking being redirected to an unsecure endpoint in a secure session, e.g. HTTPS -> HTTP

    Saturday, January 05, 2013 4:59 PM
  • I see. Well, in this case, reading the capture correctly, it seems even the redirecting is not happening. WP8 terminates the TCP/IP connection before the HTTP 30x is sent.
    Saturday, January 05, 2013 5:01 PM
  • I appreciate your effort! It's just that the same APIs and code work in WP7, nothing out of the ordinary is going on judging by the network capture and that WP8 terminates the session even before any HTTP requests are sent.

    So I guess the fallback that you mean would be for me to parse the HTTP 301 response myself, but as the connection is terminated even before any HTTP traffic is sent, I don't see how I can do anything. To me the situation looks like I am doing a TCP/IP request to a HTTPS endpoint and WP8 terminates it before I can read the reply.

    It would be very nice if someone from Microsoft or anyone else with experience from these APIs with HTTPS connection would be able to comment.

    Saturday, January 05, 2013 5:08 PM
  • Ok, so since you need to make it work you probably need to make the request and handle the redirect yourself.
    Saturday, January 05, 2013 5:08 PM
  • Problem is that I don't get any HTTP 301 redirect replies before the connection has already been terminated. So I don't know where to go after the first request.


    • Edited by Johan Paul Saturday, January 05, 2013 5:10 PM
    Saturday, January 05, 2013 5:10 PM
  • Think simple. Do a simple webclient request for the HTTPS url. Get the redirect URL and pass that to your BackgroundTransfer....
    Saturday, January 05, 2013 5:11 PM
  • Yeah. So it would be a special case for a HTTPS redirect request for WP8 devices. A nasty workaround from the app developer just because of a bug in WP8...

    I hope Microsoft will fix this soon, though.

    Saturday, January 05, 2013 5:15 PM
  • Well, I'd say its a security thing.

    You can easily handle the redirects this site is doing:

    <html><body>You are being <a href="http://ec-media.soundcloud.com/NL0tgkRDsHkk?ff61182e3c2ecefa438cd0210ad0e38569b9775ddc9e06b3c362a6833c935fe0bf91bbd0d75df123919e3a4a0851932248b50b315154b87fb43149f82e&amp;AWSAccessKeyId=AKIAJ4IAZE5EOI7PA7VQ&amp;Expires=1357406241&amp;Signature=PsTaDUc7eLqIolWvFMODYgGAU6U%3D">redirected</a>.</body></html>

    Saturday, January 05, 2013 5:20 PM
  • I see you can also just use HTTP on the same initial endpoint. Perhaps you don't need SSL? Are you using posts or gets in your backgroundtransfer?
    Saturday, January 05, 2013 5:23 PM
  • Where can you see that I use HTTP? In this (http://social.msdn.microsoft.com/Forums/getfile/216052) screenshot (this is from WP8 device) I only see TCP and SSL handshakes.

    To get the file, I use this: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh203110%28v=vs.105%29.aspx

    I guess it does a GET.


    • Edited by Johan Paul Saturday, January 05, 2013 5:31 PM
    Saturday, January 05, 2013 5:31 PM
  • You gave this url:

    https://soundcloud.com/fypfanzine/fyp-christmas-day-podcast-2012/download.mp3

    This also works:

    http://soundcloud.com/fypfanzine/fyp-christmas-day-podcast-2012/download.mp3

    Since you are using a GET that tells me you aren't passing any credentials and maybe don't need to use SSL. There may be other reasons you want to use SSL I don't know. Since this site appears to give the file when a person uses a HTTP request then perhaps you can try it and see if the backgroundtransfer will handle a HTTP to HTTP redirect. If it doesn't it can tell you that you just can't do redirects on the backgroundtransfer. In that case you may want to first use a http request and set the allowautoredirect property to false. This will give you the header and body you need to grab the redirect url and then you can pass that to your backgroundtransfer....

    Saturday, January 05, 2013 5:41 PM
  • Yeah. The URL is given by a podcast RSS feed, so I go by what they tell me. I can of course go an parse out all 'S's from the HTTPS's but... I can't be sure the same will work for all podcast feed items. Hence, it's not a solution.

    I just need to highlight that the HTTPS -> HTTP redirect works with BackgroundFileTransfer on WP7 without issues. So, we could end this by someone from Microsoft acknowledging this bug and telling us it will be fixed. I don't see any other reasonable solution.


    • Edited by Johan Paul Saturday, January 05, 2013 5:49 PM
    Saturday, January 05, 2013 5:46 PM
  • You don't see any other solution? It's really pretty simple to move forward and get your app working with a few lines of code. Simply validate each url you add to your backgroundtransfer queue. You have to show this to the end user in the UI to pass validation anyway. ;)

    MSFT may say its a bug, but they may also say it's enhanced security. Honestly, I would want to know and be able to control a system redirect from HTTPS to HTTP to ensure my customer is secure. They might argue 7 is not secure. Who knows. Do I think there could be some better control and documentation? Sure. Obviously we've spent some time on the topic when we have other things to do.

    Saturday, January 05, 2013 5:55 PM
  • :)

    What can I say. The HTTPS connection on the WP8 is terminated before any redirects are brought into the game. That's the biggest reason I think the issue is with the SSL connection and BackgroundFileTransfer/BackgroundAudioPlayer itself.

    Of course, the end users just want the app to work. And of course I want the app to work for them. I don't see the situation as simple as you. What if there's no redirect after the first HTTPS connection - I really need to download that file from HTTPS? I can't.

    But I thank you for the effort and it has been nice exchanging thoughts here. I just wish we could include MSDN a bit more.

    Have a nice weekend ;)

    Saturday, January 05, 2013 6:00 PM
  • Hi Johan,

    This appears to be the same issue as reported in the following forum post:

    http://social.msdn.microsoft.com/Forums/en-US/wpdevelop/thread/db3d70c1-a013-4bb8-bf88-39cd9a9bca63

    This was recorded into our issues database; it is currently marked as investigate.

    It appears that eschumac is likely correct in that the root cause is the redirect from HTTPS to HTTP is canceled for security reasons.

    It appears that content from other servers via HTTPS seems to work so this seems to be an issue specific to SoundCloud.

    I recommend that for now, you implement a workaround if possible; such as using HTTP instead of HTTPS, alternately you could play back content from this server by handling the redirect yourself in app code:

    public MainPage()
    {
        InitializeComponent();
    
        PlaySoundCloudTrack("https://api.soundcloud.com/tracks/66214123/stream?client_id=f17e6e71bb879390a264eef8b689a655");
    }
    
    private void PlaySoundCloudTrack(string trackUri)
    {
        HttpWebRequest req = HttpWebRequest.CreateHttp(trackUri);
        req.BeginGetResponse((result) =>
        {
            HttpWebResponse res = req.EndGetResponse(result) as HttpWebResponse;
            Dispatcher.BeginInvoke(() => myMediaElement.Source = res.ResponseUri);
        }, null);
    }

    Hope this helps,
    Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8



    Monday, January 07, 2013 3:30 PM
  • Thanks Marks for the update! Good to know that Microsoft is aware of the issue and investigating this.

    But please notice from the network traces; there is no HTTP traffic before the TCP/IP connection is terminated by WP8. Hence, I don't know how it could be related to the HTTP redirect.

    Also, please notice that this affects both BackgroundAudioPlayer and BackgroundFileTransfer.

    I can send you the original traces, if you need them.

    I also appreciate the code for the workaround. But this would not be a very useful workaround for me as it would break my UI code in the player, and I would need to rewrite download logic to use direct HTTP connection instead of BackgroundFileTransfer, which has many benefits over raw HTTP.


    • Edited by Johan Paul Monday, January 07, 2013 4:22 PM
    Monday, January 07, 2013 4:18 PM
  • I see what you mean. You are right.
    Monday, January 07, 2013 4:40 PM
  • Another thought is to work with the architects of the SoundCloud service so their service behaves the same as other streaming servers that do not show the symptom.

    -Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8


    Monday, January 07, 2013 7:14 PM