A while ago, sparkfun.com changed their URL structure from /commerce/product_info.php?products_id=9266to /products/9266This is nice, right?  We don't need to know that it is (or was) a PHP page, and commerce, product_info, and products_id all tell us that we're looking at some products.  The latter form seems like a great improvement.  However, the change would have broken existing links.  So, nicely, they stuck in 302 redirects.  Visit http://www.sparkfun.com/commerce/product_info.php?products_id=9266 and your browser will issueGET /commerce/product_info.php?products_id=9266 HTTP/1.1to which Sparkfun's servers replyHTTP/1.1 302 FoundLocation: http://www.sparkfun.com/products/9266This 302 redirect is caught by Stack Exchange's link validator as a broken link. It's not broken it works just fine.  Here, try it: http://www.sparkfun.com/commerce/product_info.php?products_id=9266I understand that a 302 redirect is intended to be a temporary redirect, while a 301 should be used for permanent changes per RFC 2616.  That said, Wikipedia and common practice use it as a redirect.  Who is in error in this situation?  Is this an error in Sparkfun's redirect implementation or in Stack Exchange's URL validator?
Should a link validator report 302 redirects as broken links?
redirects;url;302 redirect;dead links
However, the change would have broken existing links. So, nicely, they stuck in 302 redirects.Well, the important bit here is that the change would have broken existing links. /commerce/product_info.php?products_id=9266 isn't the location of the product page anymore, /products/9266 is. It's not at all unreasonable to expect the old-style links to stop working at some point - better to fix them now, while the site is happy to tell us what the proper location is, than later on when it isn't. And yes, this makes more sense for a 301 than a 302, but 302 is widely used (as in the case of your sparkfun example) for the same purpose.