-
Sompi
-
Sompi
this is ridiculous, now even DuckDuckGo doesn't work on SeaMonkey
-
Sompi
It gives an Error 400 page for certain browsers
-
nsITobin
yes on seamonkey for days then it started working again just as i was testing for it for a report
-
nsITobin
guess it is broke again?
-
nsITobin
and for more people?
-
Sompi
But user agent string override fixes it?
-
nsITobin
i never got that far
-
nsITobin
it started working again
-
nsITobin
as of 2 days ago
-
Sompi
So it is "bad request" if the user agent is not chrome or firefox
-
nsITobin
i used the default ua i assume that includes firefox and gecko compat on
-
nsITobin
am i mistaken?
-
nsITobin
i am bringing up the VM
-
Sompi
but you can also try loading the redirect page with wget and it also gets error 400
-
Sompi
and firefox also gets error 400
-
Sompi
the whole page layout is completely different for firefox
-
Sompi
nsITobin: the user agent override fixes the issue
-
Sompi
for some reason they serve a completely broken page to seamonkey
-
nsITobin
i can't reproduce it now no matter the UA
-
nsITobin
at least not on .19
-
Sompi
the search result links point to a redirect page that is broken
-
nsITobin
yes i know
-
Sompi
but why
-
Sompi
the "normal" version works with seamonkey just fine, and the user agent override proves that
-
nsITobin
i can't get it to bust
-
Sompi
so why are they serving a BROKEN page for seamonkey, a page that is so broken that it triggers a server-side error?
-
nsITobin
no matter what I feed it
-
nsITobin
you are obviously on a different instance than I am
-
nsITobin
it was a hard nginx error tho
-
nsITobin
not js generated
-
nsITobin
i remember that
-
nsITobin
is it still the same?
-
Sompi
yes
-
Sompi
just the default nginx error page for error 400
-
Sompi
it goes away if I change the user-agent string to firefox, then reload the search results and click something
-
Sompi
but if the search result page has been loaded with SeaMonkey's user-agent string, every search result link points to a redirect page that only gives that error 400
-
nsITobin
yeah i think this is only affecting a portion of ddg's servers
-
nsITobin
cause right now whatever server i am resolving to is working
-
nsITobin
no matter the UA
-
nsITobin
they may be a/b testing or it could be a cockup
-
Sompi
this just again shows how broken everything is nowadays
-
nsITobin
it seems strategic
-
Sompi
DuckDuckGo is one of the most used search engines in the world - if not the second most used ...?
-
nsITobin
because no one can really confirm anything
-
Sompi
And even it is broken like this
-
nsITobin
because right now.. the shard or instance or server I am talking to isn't doing it while you are actively having it happen
-
nsITobin
and i tried .19 .20 and wip on windows and linux and its working
-
Sompi
Seems that it's been like that for more than one year already
-
Sompi
And last three months more consistently
-
Sompi
Many users get that error every time
-
nsITobin
tho the results i am getting are not using the redirect
-
nsITobin
they are direct link save for ad placed ones
-
nsITobin
which use a redirect
-
nsITobin
y.js?ad_domain=
-
nsITobin
OKAY directly going to their redirect thing /l/ does show it as broken on Praxis (Pale Moon) and SeaMonkey..
-
nsITobin
Sompi: AND on edge
-
Sompi
Yes, it also returns error 400 to wget
-
Sompi
So the whole redirect page itself is broken
-
Sompi
But for some reason the links only point to that redirect page when I use SeaMonkey's default UA string
-
nsITobin
that part i can't reproduce anymore on my end but i did experience it days ago
-
nsITobin
but its explained by shards instances and regional delivery and rollout bs
-
nsITobin
well its giving 400 no matter what you type in to the l subdir
-
nsITobin
-
nsITobin
referencing the original bug .. why was NeilAway on about standalone composer
-
nsITobin
something just popped into my head.. WHY are we using webapps and not just api endpoints with http transport and local clients?
