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

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

Expand Messages
  • Chris Daniel
    Resynched and working :) -Chris ... -- http://www.ChrisDanielVideos.com
    Message 1 of 14 , Jul 1, 2006
    • 0 Attachment
      Resynched and working :)
       
      -Chris

       
      On 7/1/06, Erin Nealey <schmee@...> wrote:

      Thanks David, that totally fixed my problem! I'm happy now :)



      Erin Nealey
      Mom's Brag Vlog
      nealey.blogspot.com

      --- In videoblogging@yahoogroups.com, "David Howell" <taoofdavid@...>

      wrote:
      >
      > Ditto.
      >
      > I ended up resynching my feed through the Feedburner site. My latest
      video finally showed
      > up in iTunes.
      >
      > David
      > http://www.davidhowellstudios.com
      >
      > --- In videoblogging@yahoogroups.com, "Chris Daniel" <chcdaniel@> wrote:
      > >
      > > Looks like I'm having the same problem.. My latest video didn't show
      > > in my feed..
      > >
      > > -Chris
      > >
      > > On 7/1/06, Erin Nealey <schmee@> wrote:
      > > >
      > > >
      > > >
      > > >
      > > >
      > > >
      > > >
      > > > I've been having a problem with my feed lately, and just discovered
      > > > that it's only my videos that I've hosted on blip that are not
      getting
      > > > picked up. I contacted Feedburner, and they said they are working on
      > > > figuring out why, but I thought I'd shoot this out to the list
      to see
      > > > if anyone has had this problem or might know how this happened.
      Mike,
      > > > Charles, Jarrett.. anyone?
      > > >
      > > > Erin Nealey
      > > > Mom's Brag Vlog
      > > > nealey.blogspot.com
      > > >
      > > >
      > >
      > >
      > >
      > > --
      > > http://www.ChrisDanielVideos.com
      > >
      >




      --
      http://www.ChrisDanielVideos.com
    • David Meade
      ... 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
      Message 2 of 14 , Jul 1, 2006
      • 0 Attachment
        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
        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 3 of 14 , Jul 1, 2006
        • 0 Attachment
          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 4 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 5 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 6 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 7 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 8 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.