Content-Location non-bug/bug dilemma

[Olivier Goffart]

Le Vendredi 23 Décembre 2005 05:38, Dawit Alemayehu a écrit :
> Hello,
>
> The following patch is meant to address BR# 82747:
> http://bugs.kde.org/show_bug.cgi?id=82747
>
> It reverts a patch that fixed BR# 51185:
> http://bugs.kde.org/show_bug.cgi?id=51185
>
> Following a standard is worthless if we are the only ones that do it. Every
> other major browser seems to break this. At least Mozilla/Firefox does.
> Anyways, I want to bring this up for discussion here because this breaks
> starndard compliant behavior.

Hello, 
I had to patch my khtml localy to complete my inscription to the university 
this year.

They set a Content-Location: http://127.0.0.1/xxxxxx

I told the admin this is wrong, but he replied it is there for internal 
reason, an that i had to use firefox.  (but i used my patched konqueror 
anyway)

I did some research to know if konqueror was wrong or right,  It seems 
Konqueror does the right way,   but mozilla was a bit more pragmatic:
https://bugzilla.mozilla.org/show_bug.cgi?id=109553
They don't want to fix that because it fail with some website

Note that i noticed a workaround:  clicking on a link doesn't work (it gives 
404) , but when going back, the content-location: header is not interpreted 
anymore => you can surf by clicking then back then clicking  (this is a bug 
anyway)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20051223/08adb9a9/attachment.sig>