Loading ...
Sorry, an error occurred while loading the content.
 

Re: [videoblogging] Re: Feedburner and Blip (problems)

Expand Messages
  • Mike Hudack
    Hey guys, Just to clear this up: 30x redirects are *not* supposed to return the content type they re pointing to. They re supposed to return either text/html
    Message 1 of 14 , Jul 1, 2006
      Hey guys,

      Just to clear this up: 30x redirects are *not* supposed to return the content type they're pointing to.  They're supposed to return either text/html or text/plain.  The rationale is that if the Web browser doesn't support redirects the user will see some HTML or plain text telling them that they're supposed to go somewhere else.

      There's a bit of interesting (if technical) example on Wikipedia:

      http://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx

      The problem with FeedBurner is related to a hack we put in place months ago because FeedBurner was having trouble following redirects in the first place (they were saying they "timed out" for services from blip to flickr).  So we stopped redirecting them as such as and started sending them straight to the media file, on the theory that they were only doing a HEAD request (and not getting the whole file).

      Since then, things have changed on both the FeedBurner and blip sides (at least that's the way it looks) and for some reason that hack stopped working.  So yesterday we started treating FeedBurner like everyone else again, and that seems to be working.  We'll keep an eye out for timeouts again and we'll have to reevaluate if we start seeing them.

      So, long story short: Should be working again.  If your media isn't showing up in your FeedBurner feed ask FeedBurner to refresh the feed.  If you're still having trouble drop an e-mail to blip support and we'll track it down and get in touch with FeedBurner if we have to.

      Yours,

      Mike

      On 7/1/06, David Meade <meade.dave@...> wrote:


      On 7/1/06, jchavezb < jessiec@...> wrote:
      Hi Erin,

      It seems Blip.tv is now returning the correct response which is a
      redirect to the media file with the correct content-type.  For a while
      there, it was returning a content type of html to the file request
      from our user agent.

      Let us know if you see any further issues and we'd be glad to follow up.

      Thanks,
      Jessie Chavez
      Feedburner Engineering Team


      Jessie, I'm a bit confused by this.  As it turns out, I have a few tickets open witht he IE7 beta 3 team in regards to a few bugs I found, and one of them relates to (I believe) how it handles the content-type returned from redirects, so I'm very interested in this.  If you'll forgive my ignorance, I'd love to ask you a few questions ...

      I just did some header checks and:

      1) It appears the blip redirect is (still) returning "text/html; charset=iso-8859-1"
      2) 302 redirects are supposed to return the content type they point to!? 
      3) If so, should they return the content type they point to, or to the resource at the end of the redirect chain?
      4) I have feedburners download tracking turned on and this redirect - although it does return video/quicktime .. does not point to my movie but to ANOTHER feedburner redirect ... which returns "text/plain".  Shouldn't this final feedburner redirect then also return "video/quicktime"?
      5) If the 302 content-type should return the content type it points to ... what if it points to another redirect, which points to a video?  This seems to be the case for a feedburner download tracking url.  Oddly the content types returned by feed burner seem backwards (video->text)

      It seems I'm in the following situation.  My enclosures go through several redirects in this order:

      feedburner1 -->  feedburner2 --> blip1 --> MovieFile

      And the above path returnes the following content-types:

      video/quicktime  --> text/plain  -->  text/html; charset=iso-8859-1 --> video/quicktime

      It seems to me, that if there is a rule about the content-type given by a redirect, both blip and feedburner are still breaking the rule.


      Doesnt it make more sense to discount the content type given in a "300" redirect and use the content type from fir first resulting "200" successful http request?

      - Dave

      --
      http://www.DavidMeade.com
      feed:   http://www.DavidMeade.com/feed


    • Andreas Haugstrup
      On Sat, 01 Jul 2006 17:36:20 +0200, David Meade ... Shouldn t be a problem (it s a Feedburner problem if this is the cause). ... No. On
      Message 2 of 14 , Jul 1, 2006
        On Sat, 01 Jul 2006 17:36:20 +0200, David Meade <meade.dave@...>
        wrote:

        > 1) It appears the blip redirect is (still) returning "text/html;
        > charset=iso-8859-1"

        Shouldn't be a problem (it's a Feedburner problem if this is the cause).

        > 2) 302 redirects are supposed to return the content type they point to!?

        No. On GET requests servers are supposed to include a short hypertext link
        to the redirect location on a 302. Makes sense since you can run into user
        agents that don't understand the 302. Returning text/html along with a 302
        is perfectly normal no matter what lies behind the redirect.

        --
        Andreas Haugstrup Pedersen
        <URL: http://www.solitude.dk/ >
        Commentary on media, communication, culture and technology.
      • jchavezb
        Hi David, The issue earlier this week was that Blip.tv was returning a 200 text/html (not a 302) when our user agent (using the header Feedburner
        Message 3 of 14 , Jul 1, 2006
          Hi David,

          The issue earlier this week was that Blip.tv was returning a 200
          text/html (not a 302) when our user agent (using the header Feedburner
          1.0/http://www.feedburner.com) made a request for a media file hosted
          there.

          It's now working correctly in which they return 302's (content type
          doesn't matter here but it's text/html) and eventually get to a 200
          with the correct media mime type. This is the 'standard' way it
          usually works and we handle correctly, as most web clients.

          The issue was simply the incorrect response to a non-browser user
          agent at blip which now seems to be corrected. It was working fine in
          a browser window (which uses a browser user agent) which is why it was
          hard to find the issue.

          Hope this helps.

          Thanks,
          Jessie Chavez
          Feedburner Engineering Team



          --- In videoblogging@yahoogroups.com, "David Meade" <meade.dave@...>
          wrote:
          >
          > On 7/1/06, jchavezb <jessiec@...> wrote:
          > >
          > > Hi Erin,
          > >
          > > It seems Blip.tv is now returning the correct response which is a
          > > redirect to the media file with the correct content-type. For a while
          > > there, it was returning a content type of html to the file request
          > > from our user agent.
          > >
          > > Let us know if you see any further issues and we'd be glad to
          follow up.
          > >
          > > Thanks,
          > > Jessie Chavez
          > > Feedburner Engineering Team
          >
          >
          >
          > Jessie, I'm a bit confused by this. As it turns out, I have a few
          tickets
          > open witht he IE7 beta 3 team in regards to a few bugs I found, and
          one of
          > them relates to (I believe) how it handles the content-type returned
          from
          > redirects, so I'm very interested in this. If you'll forgive my
          ignorance,
          > I'd love to ask you a few questions ...
          >
          > I just did some header checks and:
          >
          > 1) It appears the blip redirect is (still) returning "text/html;
          > charset=iso-8859-1"
          > 2) 302 redirects are supposed to return the content type they point to!?
          > 3) If so, should they return the content type they point to, or to the
          > resource at the end of the redirect chain?
          > 4) I have feedburners download tracking turned on and this redirect -
          > although it does return video/quicktime .. does not point to my
          movie but to
          > ANOTHER feedburner redirect ... which returns "text/plain".
          Shouldn't this
          > final feedburner redirect then also return "video/quicktime"?
          > 5) If the 302 content-type should return the content type it points
          to ...
          > what if it points to another redirect, which points to a video?
          This seems
          > to be the case for a feedburner download tracking url. Oddly the
          content
          > types returned by feed burner seem backwards (video->text)
          >
          > It seems I'm in the following situation. My enclosures go through
          several
          > redirects in this order:
          >
          > feedburner1 --> feedburner2 --> blip1 --> MovieFile
          >
          > And the above path returnes the following content-types:
          >
          > video/quicktime --> text/plain --> text/html; charset=iso-8859-1 -->
          > video/quicktime
          >
          > It seems to me, that if there is a rule about the content-type given
          by a
          > redirect, both blip and feedburner are still breaking the rule.
          >
          > Doesnt it make more sense to discount the content type given in a "300"
          > redirect and use the content type from fir first resulting "200"
          successful
          > http request?
          >
          > - Dave
          >
          > --
          > http://www.DavidMeade.com
          > feed: http://www.DavidMeade.com/feed
          >
        • Mike Hudack
          Yup, that s pretty much it. -mike (blip.tv)
          Message 4 of 14 , Jul 1, 2006
            Yup, that's pretty much it. 

            -mike (blip.tv)

            On 7/1/06, jchavezb <jessiec@... > wrote:

            Hi David,

            The issue earlier this week was that Blip.tv was returning a 200
            text/html (not a 302) when our user agent (using the header Feedburner
            1.0/http://www.feedburner.com) made a request for a media file hosted
            there.

            It's now working correctly in which they return 302's (content type
            doesn't matter here but it's text/html) and eventually get to a 200
            with the correct media mime type. This is the 'standard' way it
            usually works and we handle correctly, as most web clients.

            The issue was simply the incorrect response to a non-browser user
            agent at blip which now seems to be corrected. It was working fine in
            a browser window (which uses a browser user agent) which is why it was
            hard to find the issue.

            Hope this helps.



            Thanks,
            Jessie Chavez
            Feedburner Engineering Team

            --- In videoblogging@yahoogroups.com, "David Meade" <meade.dave@...>
            wrote:

            >
            > On 7/1/06, jchavezb <jessiec@...> wrote:
            > >
            > > Hi Erin,
            > >
            > > It seems Blip.tv is now returning the correct response which is a
            > > redirect to the media file with the correct content-type. For a while
            > > there, it was returning a content type of html to the file request
            > > from our user agent.
            > >
            > > Let us know if you see any further issues and we'd be glad to
            follow up.
            > >
            > > Thanks,
            > > Jessie Chavez
            > > Feedburner Engineering Team
            >
            >
            >
            > Jessie, I'm a bit confused by this. As it turns out, I have a few
            tickets
            > open witht he IE7 beta 3 team in regards to a few bugs I found, and
            one of
            > them relates to (I believe) how it handles the content-type returned
            from
            > redirects, so I'm very interested in this. If you'll forgive my
            ignorance,
            > I'd love to ask you a few questions ...
            >
            > I just did some header checks and:
            >
            > 1) It appears the blip redirect is (still) returning "text/html;
            > charset=iso-8859-1"
            > 2) 302 redirects are supposed to return the content type they point to!?
            > 3) If so, should they return the content type they point to, or to the
            > resource at the end of the redirect chain?
            > 4) I have feedburners download tracking turned on and this redirect -
            > although it does return video/quicktime .. does not point to my
            movie but to
            > ANOTHER feedburner redirect ... which returns "text/plain".
            Shouldn't this
            > final feedburner redirect then also return "video/quicktime"?
            > 5) If the 302 content-type should return the content type it points
            to ...
            > what if it points to another redirect, which points to a video?
            This seems
            > to be the case for a feedburner download tracking url. Oddly the
            content
            > types returned by feed burner seem backwards (video->text)
            >
            > It seems I'm in the following situation. My enclosures go through
            several
            > redirects in this order:
            >
            > feedburner1 --> feedburner2 --> blip1 --> MovieFile
            >
            > And the above path returnes the following content-types:
            >
            > video/quicktime --> text/plain --> text/html; charset=iso-8859-1 -->
            > video/quicktime
            >
            > It seems to me, that if there is a rule about the content-type given
            by a
            > redirect, both blip and feedburner are still breaking the rule.
            >
            > Doesnt it make more sense to discount the content type given in a "300"
            > redirect and use the content type from fir first resulting "200"
            successful
            > http request?
            >
            > - Dave
            >
            > --
            > http://www.DavidMeade.com
            > feed: http://www.DavidMeade.com/feed
            >


          • David Meade
            ... Ok good, thats what I thought. So Jessie, should I be concerned that one of my feedburner redirects is returning a video content-type when it fact its just
            Message 5 of 14 , Jul 1, 2006
              On 7/1/06, Andreas Haugstrup <solitude@...> wrote:
              No. On GET requests servers are supposed to include a short hypertext link
              to the redirect location on a 302. Makes sense since you can run into user
              agents that don't understand the 302. Returning text/html along with a 302
              is perfectly normal no matter what lies behind the redirect.

              Ok good, thats what I thought.

              So Jessie, should I be concerned that one of my feedburner redirects is returning a video content-type when it fact its just point to yet another 302?

              This may verywell be whats causing one of the IE7beta3 error I'm seeing.  IE7beta3 has an auto-download enclosures feature for feeds, but on some feeds the QuickTime files download are getting corrupted "not a movie file" even though they are perfectly fine QT files.  If IE7 is getting a video content type on a redirect it might account for how it's managing to download something other than the valid movie file.

              I realize this is an IE bug not a feedburner one ... but maybe it would be best to return a text based content type on the redirects you offer?

              --
              http://www.DavidMeade.com
              feed:  http://www.DavidMeade.com/feed
            • jchavezb
              Interesting issue. I ll check with the team to see if anyone has already run into this or is working on investigating this. If it s not too much trouble, it
              Message 6 of 14 , Jul 1, 2006
                Interesting issue. I'll check with the team to see if anyone has
                already run into this or is working on investigating this.

                If it's not too much trouble, it would be a great help if you could
                post a specific example of this to our forums or email at
                feedback@... That way, we have a concrete example to start
                investigating right away.








                --- In videoblogging@yahoogroups.com, "David Meade" <meade.dave@...>
                wrote:
                >
                > On 7/1/06, Andreas Haugstrup <solitude@...> wrote:
                > >
                > > No. On GET requests servers are supposed to include a short
                hypertext link
                > > to the redirect location on a 302. Makes sense since you can run
                into user
                > > agents that don't understand the 302. Returning text/html along
                with a 302
                > > is perfectly normal no matter what lies behind the redirect.
                > >
                >
                > Ok good, thats what I thought.
                >
                > So Jessie, should I be concerned that one of my feedburner redirects is
                > returning a video content-type when it fact its just point to yet
                another
                > 302?
                >
                > This may verywell be whats causing one of the IE7beta3 error I'm seeing.
                > IE7beta3 has an auto-download enclosures feature for feeds, but on some
                > feeds the QuickTime files download are getting corrupted "not a
                movie file"
                > even though they are perfectly fine QT files. If IE7 is getting a video
                > content type on a redirect it might account for how it's managing to
                > download something other than the valid movie file.
                >
                > I realize this is an IE bug not a feedburner one ... but maybe it
                would be
                > best to return a text based content type on the redirects you offer?
                >
                > --
                > http://www.DavidMeade.com
                > feed: http://www.DavidMeade.com/feed
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.