I will hopefully soon work on that. My last ideas are to
1. Use 303 has default being defined with a property in general.properties (or widget.properties?) to override for all OFBiz webapps
in case
2. Add an element in controller to be able to override in a sole controller. For instance you would want the 303 default for all
webapps but eCommerce where you want all redirects being 302. We could even refine more and have a type in this specific element. or
isntance use 302 only for url type and not simple redirects (to separate concerns about double-submit and SEO)
So everybosdy will be able to use it the way it suits him/her best.
I don't think a Jira is needed, else please say it know
Jacques
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
Unless I'm mistaken crawlers don't follow post urls, they only follow links so I doubt it would really matter from an SEO
perspective what code we used when doing a post redirect. I really only commented to avoid a blanket change to 301 being
introduced.
Thanks for your answer, I tend to lean more on a configurable setting (I called option 3, like the status-code attribute you
suggested)
Obviously the url response type is not related to the double submit issue. We use it in some place because it's an easy go
compared with Front End rewrite rules (external to OFBIz) or even Tuckey (internal)
If you want to be able to do a permanent redirect then I'd consider naming them as such instead of using the response codes e.g.
request-redirect-permanent or url-permanent.
Maybe an option is to allow a status-code attribute on the response element? It could be used for a number of things even
outside of redirects.
Yes those were the alternatives I was spkeaking about below. I did not think about use outside of redirects though, have you any
ideas yet?
My plan would be:
1) Change the default because 302 is horrible. Not sure what it should be yet,
303 seems the least problematic (over 301)
2) Choose between
a) "harcoded" names like request-redirect-permanent or url-permanent (we have
also cross-redirect and request-redirect-noparam)
b) a status-code attribute on the response element
i) See if there are other uses for status-code than redirect response
types
So we still need to investigate for the default value and make a choose between a lot of type of redirect and a new status-code
response attribute
Jacques
Regards
Scott
On 26/06/2012, at 10:03 PM, Jacques Le Roux wrote:
I suggested initially to use the more open 3rd option, we could use 301, 302
and 303?
For the difference between 301 vs 307 I think we can agree on : <<The difference between the two being that you shouldn't use
the
307 as it is not understood by many agents. (simple ehy )>>
http://jesperastrom.com/seo/different-variations-of-redirects-301-302-303-304-etc/
For 302, I don't see any needs, apart in case of temporary errors which should not happen (You will have still the bots keeping
the
initial link referenced)
What I did not talk about is the default, so you would suggest to use 303,
right?
The problem is most people will never notice it and it seems 303 is not good
for SEO and eCommerce
I Googled for "303 seo"
1st answers: http://sharkseo.com/nohat/303-redirects-seo/
http://www.marketingchip.com/seo-experiments/how-does-a-303-redirect-affect-seo/
But found also answers saying it was not much an issue
like at http://www.seomoz.org/q/usage-of-http-status-code-303 , I read at bottom
"however technically if there are no inbound links pointing to the pages that you want to 303 redirect, it will not hurt your
seo."
At some point I thought we could introduce request-redirect-303 for form and mostly backend side (maybe keeping
request-redirect-303
named request-redirect for the sake of simplicity) and request-redirect-301 for eCommerce when you need to do redirections
without
fearing double submits. But then we would have to also duplicate all others
redirect response types :/
I'm now perplexed and need more time to check about this sentence and our
current OOTB situation, at
http://en.wikipedia.org/wiki/Post/Redirect/Get I read
"However, HTTP 301 may be preferred in cases where it is not desirable for POST
parameters to be converted to GET parameters and
thus be recorded in logs."
Sorry for the long post, seems that we need to get into details
Jacques
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
Right, so they recommend using 301 for a permanent redirect but like I said, the bulk of our redirects (as far as I am aware)
are
used for Post Redirects which 301 isn't appropriate for.
Regards
Scott
On 26/06/2012, at 2:15 AM, Jacques Le Roux wrote:
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=93633
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=40132
http://searchengineland.com/images/301-302-explained.gif
HTH
Jacques
From: "Scott Gray" <scott.g...@hotwaxmedia.com>
I think most of our redirects OOTB are used as a Post/Redirect/Get pattern for which 303 is best on HTTP 1.1 or 302 on HTTP
1.0
http://en.wikipedia.org/wiki/Post/Redirect/Get
Do you have a reference for your SEO best practices? Or alternatively do you
have an example of where a 301 redirect would be
more appropriate in the ecommerce app?
Regards
Scott
On 25/06/2012, at 8:07 AM, Jacques Le Roux wrote:
This is the easiest way to go, so I'm not against, no other opinions?
Jacques
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
A 301 permanent replacement makes sense to me.
-Adrian
On 6/22/2012 8:47 PM, Jacques Le Roux wrote:
Hi,
Since all redirect response types (url, cross-redirect, request-redirect,
request-redirect-noparam) call
HttpServletResponse.sendRedirect() through RequestHandler.callRedirect(), all controllers redirections do 302
redirections.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection
To keep short:
301: permanent redirect
302: temporary redirect
SEO best practices recommend to use 301 instead of 302 (just Google for "301 vs
302")
Of course this does not matter much for an ERP only used in an intranet, but
for eCommerce it matters.
So we have 3 solutions at hand:
1. Keep as is (ie continue with a 302 redirect)
2. Permanently replace the 302 redirect by a 301
3. Offer an option between the 2 (or even others if we want, like 307).
If we choice 3, what name would you pick for this option ("redirect-type", between
{"301","302"}?). Then it would not have
any sense for non redirect response types, maybe a reason to prefer option 2.
Though a temporary redirect could still be
useful in case of redirection on error, hence my preference for 3...
What's your opinion?
Jacques
