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

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

Expand Messages
  • 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 1 of 14 , Jul 1, 2006
    • 0 Attachment
      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 2 of 14 , Jul 1, 2006
      • 0 Attachment
        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 3 of 14 , Jul 1, 2006
        • 0 Attachment
          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 4 of 14 , Jul 1, 2006
          • 0 Attachment
            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 5 of 14 , Jul 1, 2006
            • 0 Attachment
              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.