A 301 response rather than a 302 would be better wouldn`t it?

Do you mean when someone submits a link and you click download on it?

1) The only difference I could see between the two headers would be for search engines, and I wouldn't imagine too many people allow search engine spiders to download files

2) I just use the ipsclass->boink_it method (the same redirect method used for every single no-page immediate redirect in IPB)

nah I mean when an automodule link is clicked it`s redirected to the autocom link and a 302 status is logged.

A 302 is temporary meaning a search engine won`t update it`s cache with the new link, so you`ll end up with pages being cached twice under the two link formats and getting duplicate content penalties as a result.

A 301 is permanent so the old automodule links will be replaced with the new autocom one`s in the search engine cache and no dup content penalties.

The w3 status code definitions in the links above have a good brief description of these two codes and their behaviour. Seems to me a 301 would be better suited all round. Also they mention that the 301 is cacheable, although I`m not entirely sure exactly what that means I get the feeling it could be a good thing aswell.

I know the difference between the two....again, though, I just use the IPB method boink_it. IPB would have to be updated to send a 301 before doing the redirect, but the problem is some links may only be redirected temporary.

I don`t understand which links are temporary? All IPD links are now autocom aren`t they.. so that`s a permanent change and a 301 is necessary. Otherwise duplicate content chaos.

I don`t wish to be orkward, you see the situation...

Hello,

No, the change from autocom to automodule is permanant.

But what I'm saying is, this is the code that I use to do the redirect



If you go look at the ipsclass boink_it method, it just does the header("Location:..."); redirect - BUT what I was trying to explain is that every single no-page redirect in IPB, Gallery and Blog uses this redirect, not just IDM. In order to "fix"t his, IPB needs to be updated.

ok. obviously changes will need to be made if your going to change it. I understand now that you can`t just stop using the built in redirect and code IPD to feed a 301.

So the question is are you going to update IPB to acheive this? I would really like it if you would because I can`t live with dup content, TBO I`m supprised knowone else has brought this up already.

hehe whenever the redirect page comes up now, I`ll think, boink lol

I would like to upgrade Brandon, but can`t untill this is changed. So will it be changed in the next IPB release?

If it will be that would make me a VERY happy customer. Since I`d not need to spend further cash on a custom modification.

Thank you.

So the diffrence between 302 and 301 affects only spiders?

I'd say hit this up in Bug Tracker if Brandon see's fit... but from what I read I'd set it was a low priority. If the affect is temporary (the double cache) as brandon states then I really don't see much of an issue in the diffrence.

My 2c

Grizli - this is how IPB has worked for....well....forever.

It's easy to change if it's THAT big a deal to you. Open sources/ipsclass.php, find



and add after it

Brandon - I understand this is how IPB has always worked and it`s fine to continue to do so.

I feel your not grasping what the situation is, so allow me to walk through it and I apologise in advance if this is alredy clear to you.

This is a seperate issue caused by the failure to use a proper redirect for a permanent link change. As in, useing the boink instead of a 301 for the new download link URL.

Imagine google hits index.php?automodule=downloads&showfile=1

It`s redirected to index.php?autocom=downloads&showfile=1

and indexes the new autocom link, now their are two indexed links to the same content. So google slaps us with a dup content penalty.

If a 301 was used when redirecting the old automodule link to the new autocom link, google would drop the old link, cache the new one and we wouldn`t get a dup content penalty.

The boink is fine for redirecting one page to another as it`s currently used for, but for permanent link changes a 301 is more appropriate and indeed absolutely necessary for anyone wanting to avoide duplicate content issues.


Correct me if I`m wrong, the code you posted makes it so all IPB redirects are now 301, which is not what we need. A 301 should only be fed for the new download URLs.

Thank You

I'm afraid I'm NOT not going to use the boink_it method. This method takes into account the "Redirect type" in the ACP - i.e. if your files have whitespace or other issues, you can change it to use an HTML-meta redirect type, and the boink-it method uses this.

It does not make sense to not use the class methods already available to accomplish something.

If the 302 vs 301 redirect type is important to you, you are certainly free to modify the software to accomplish this. Or even better, add an .htaccess to accomplish this. I've simply provided, as a courtesy, a quick redirect from automodule to autocom so that existing links won't be broken.

Good, there is no need to stop useing it altogether! That would be wrong.


I would agree if sending a 301 wasn`t the logical thing to do for the reason I`ve already explained.


If I was able to modify the code myself I would of done so already. htaccess is an option but it adds overhead. What would be better is it being coded into IPB as it should of been in the first place. Why won`t you do this? Only reason I can think of is pride because there are no other reasons not to. It would improve IPB and cause less grief for users.


Ye right, as a courtesy, like there wouldn`t of been uproar if you`d broken all the download links! Which is effectivly what you have done anyway by not going down the logical route.

How about useing a 301 for the autocom redirect like it should of been in the first place and stop taking this personnaly.

Perhaps it would make sense to extend boink_it to accomodate different header types, this way not only IDM, but any area of IPB that should use a 301 method can and those that should use a 302 method also can.

Something like:

Thanks Professor, that sounds like an ideal solution. Forgive my ignorance.. or lack of coding skills though, how would that work and is it supposed to replace the whole boink_it function in ipsclass.php?

You could also try adding the header call I mentioned in modules/downloads.php before the boink_it call, as it should send the header, but would obviously only apply when the automodule links are called and not all IPB redirects.

Time to sort this... I guess from what your saying Brandon to add



before



in modules/downloads/downloads.php

Is this right because there`s no function boink_it($url) in modules/downloads/downloads.php ?

No, you add that line before a line that looks like (in that file)

$this->ipsclass->boink_it( ... );

There are several instances of that so I just put it infront of every one but still 302 is returned.

btw I`m useing firefox extension Live HTTP Headers to check.. it`s excellant.

Any idea why it doesn`t work Brandon?

Thanks to Michael at invisionmodding.com for helping find a solution and for anyone wanting to prevent IPB causing duplicate content issues:

modules/mod_downloads.php
FIND

ADD ABOVE