Back to Top

Dealing w/ authenticating proxies

2 posts / 0 new
Last post
Last seen: 10 years 2 months ago
Joined: 11/12/2009 - 10:38
Dealing w/ authenticating proxies

I have a problem downloading podcasts that technically isn't Doggcatcher's fault, but I'm hoping you might consider an app change to better deal with this situation.

It involves downloading podcast on corporate networks on wifi where add'l authentication or authorization is required.

Here's the scenario:
1.) I have DC set to only download on wifi
2.) It appears that DC still checks for new feeds even when not on wifi (that's ok ... i don't mind)
3.) I have wifi turned on on my phone
4.) I get into work, and my phone automatically connects to the guest wifi network there (we're a large company w/ a lot of security)
5.) Before you can use the network, you must visit a page where you muse 'accept' a good behviour policy ... so before you do this, even though the phone's connected to wifi, that really isn't usable to access the internet
6.) However, DC sees the wifi as connected, so it proceeds to start downloading podcasts
7.) DC *thinks* everything is OK ... it goes to download a file, and data gets returned
8.) The problem: that data is *not* the podcast I intended (say, a MP3) ... instead it is the contents of the "click here to accept our wifi policy" HTML page from our corporate network, which intercepted the request. (if you'd like I can send an example (no attaching files here?) ... DC thinks it's a MP3 ... but it you open it in notepad or a text editor, you'll see it's HTML)
9.) However, since DC got data, and presumably a HTTP 200 OK code ... it thinks all is good. It saves the file and moves on.
10.) needless to say, when I go to play the podcast, the play fails ... DC can't 'play' a MP3 file that contains HTML (nor would I want it to) .. I have to delete media and re-download.
11.) eventually at some point I'll pick up the phone, and in my phone's browser I'll get the 'accept' page ... at that point I'll accept it and now have internet access ... however at this point it's usually too late for any downloads that DC tried beforehand

So ... I'm wondering if there's a way to make this work better/smoother. Thoughts/options on how to deal with this:
1.) Validate that a file is type that it says it is (e.g., a mp3 is a mp3)
2.) If that's too difficult, at least check the file for HTML when it claims to be audio or video
3.) Have DC perform a 'pre-check' that it has full internet access by downloading a known 'test file/page' on a trusted site ( before it starts downloading podcasts. Maybe have 2-3 test locations that DC can try in case 1 of them goes down; as long as one works, assume we're OK
4.) Some sort of size validation ... ie, reject a file if it is less than a set 'acceptable' size for a podcast (say < 1 MB, or at least 20% the size of what this podcast normally is)

Obviously any of these options could be optional and only toggled on by folks like me who could use them.

An additional consideration is that, if you implement some/any of the suggestions above, to optionally have DC give a notification if it is having problems downloading. That would serve as a trigger for me to know to go click 'accept' so that internet access is allowed.

Thanks for the consideration. (btw ... I'm the guy who notified you a year or so ago that the domain was now available to grab ... good to see you're getting value out of it)


Last seen: 1 year 6 months ago
Joined: 11/06/2008 - 22:02
I really like those ideas. A

I really like those ideas.

A few months ago, I added some checking to make sure we were getting a 200 response code before downloading. That has helped quite a bit, and I think that proxies should be setting an alternate response code when they don't provide the resource that was actually requested...maybe a temporary redirect code or something.

But....since we can't make that happen, I'll try to do what I can to help this. I think it happens to people a lot more than we realize. We probably just see it as what looks like a media player failed of some kind, then the user will re-download the file and it will be fixed...not the best experience.

You've got the possible solutions pretty well covered. I'm leaning towards the check for a valid site because it would prevent a bad download rather than starting and aborting. That's how windows knows when you've got a valid net connection. The drawback here is that if that known valid site goes away, DC is dead.

I'll need to think about this some more to know how to fix it but I'm thinking that it would need to be a preference you can enable (at least at first).

I created an issue for this, thanks for going into such great detail.

Oh, and thanks also for helping me get the domain. :-)