HTTP 303 after submit (wiki pages updates, ticket creation, Admin Customizations, Milestone editions, and so on...)

[Fabio]

Hi,

I'm evaluating Trac (and it really tops my expectations), but a
strange error is causing a poor user experience: most of the pages
fails into HTTP 303 response after submitting changes. Although this
bad effect, the updates become effective. It is similar to bugs
reported in

http://trac.edgewall.org/ticket/8583

and in

http://trac.edgewall.org/ticket/7060


Scenario description:
- Trac 0.11.5 installation
- tracd is serving the project
- user has TRAC_ADMIN permission
- tracd web front-end fails after submitting data (HTTP 303 is
displayed at server console window)
- It's necessary to use back and refresh buttons to view changes
become effective.
- tracd IS NOT behind a proxy


Any insights on how to fix it?
Thanks in advance,
Fabio.

[Christian Boos]

Fabio wrote:
> Hi,
>
> I'm evaluating Trac (and it really tops my expectations), but a
> strange error is causing a poor user experience: most of the pages
> fails into HTTP 303 response after submitting changes. Although this
> bad effect, the updates become effective.

303 is not a failure code, but a redirect.
Trac uses the "POST-redirect-GET" idiom, which is good practice in web
applications [1].
This can lead to, as with any other redirects, some issues with getting
the protocol and host right, hence the discussion about
use_base_url_for_redirect in the ticket 7060.

> It is similar to bugs
> reported in
>
> http://trac.edgewall.org/ticket/8583
>
> and in
>
> http://trac.edgewall.org/ticket/7060
>
>

> Scenario description:
> - Trac 0.11.5 installation
> - tracd is serving the project
> - user has TRAC_ADMIN permission
> - tracd web front-end fails after submitting data (HTTP 303 is
> displayed at server console window)
>

That's expected so far.

> - It's necessary to use back and refresh buttons to view changes
> become effective.
>

Which browser are you using? Chances are this is IE7.

> - tracd IS NOT behind a proxy
>
>
> Any insights on how to fix it?
>

Use the --http11 option when running tracd. Besides fixing your problem
(likely the http://trac.edgewall.org/ticket/8020 one), you'll also get a
nice performance boost ;-)

-- Christian

[1] http://en.wikipedia.org/wiki/Post/Redirect/Get

[Fabio]

Thanks, it worked!

> (likely thehttp://trac.edgewall.org/ticket/8020one), you'll also get a

> nice performance boost ;-)
>
> -- Christian
>

> [1]http://en.wikipedia.org/wiki/Post/Redirect/Get- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[rupert.thurner]

> (likely thehttp://trac.edgewall.org/ticket/8020one), you'll also get a
> nice performance boost ;-)

christian, would it be possible to make this the default?

rupert.

[Christian Boos]

It's the case now for 0.12dev [1].

Depending on the feedback, we could make it the default for 0.11.6 as
well, but this change may break some plugins: any plugin which sends a
response without setting the Content-Length properly will make the
browser "hang" [2]. Trac proper does everything proper AFAICT, but I
have no idea if plugins behave well in this area.

-- Christian

[1] - http://trac.edgewall.org/changeset/8570
[2] - http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#tracdandHTTP1.1