15:09:49 <Sompi> https://www.reddit.com/r/duckduckgo/comments/1g6mw31/anyone_else_getting_400_bad_request/
15:10:02 <Sompi> this is ridiculous, now even DuckDuckGo doesn't work on SeaMonkey
15:10:10 <Sompi> It gives an Error 400 page for certain browsers
15:10:11 <nsITobin> yes on seamonkey for days then it started working again just as i was testing for it for a report
15:10:23 <nsITobin> guess it is broke again?
15:10:27 <nsITobin> and for more people?
15:10:31 <Sompi> But user agent string override fixes it?
15:10:40 <nsITobin> i never got that far
15:10:44 <nsITobin> it started working again
15:10:50 <nsITobin> as of 2 days ago
15:11:05 <Sompi> So it is "bad request" if the user agent is not chrome or firefox
15:11:29 <nsITobin> i used the default ua i assume that includes firefox and gecko compat on
15:11:32 <nsITobin> am i mistaken?
15:12:11 <nsITobin> i am bringing up the VM
15:12:22 <Sompi> but you can also try loading the redirect page with wget and it also gets error 400
15:13:21 <Sompi> and firefox also gets error 400
15:14:07 <Sompi> the whole page layout is completely different for firefox
15:14:37 <Sompi> nsITobin: the user agent override fixes the issue
15:14:46 <Sompi> for some reason they serve a completely broken page to seamonkey
15:14:50 <nsITobin> i can't reproduce it now no matter the UA
15:14:57 <nsITobin> at least not on .19
15:15:00 <Sompi> the search result links point to a redirect page that is broken
15:15:24 <nsITobin> yes i know
15:15:50 <Sompi> but why
15:16:05 <Sompi> the "normal" version works with seamonkey just fine, and the user agent override proves that
15:16:24 <nsITobin> i can't get it to bust
15:16:27 <Sompi> so why are they serving a BROKEN page for seamonkey, a page that is so broken that it triggers a server-side error?
15:16:30 <nsITobin> no matter what I feed it
15:16:41 <nsITobin> you are obviously on a different instance than I am
15:17:12 <nsITobin> it was a hard nginx error tho
15:17:15 <nsITobin> not js generated
15:17:20 <nsITobin> i remember that
15:17:24 <nsITobin> is it still the same?
15:18:57 <Sompi> yes
15:19:23 <Sompi> just the default nginx error page for error 400
15:19:53 <Sompi> it goes away if I change the user-agent string to firefox, then reload the search results and click something
15:20:40 <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
15:21:09 <nsITobin> yeah i think this is only affecting a portion of ddg's servers
15:21:21 <nsITobin> cause right now whatever server i am resolving to is working
15:21:24 <nsITobin> no matter the UA
15:22:14 <nsITobin> they may be a/b testing or it could be a cockup
15:22:38 <Sompi> this just again shows how broken everything is nowadays
15:22:56 <nsITobin> it seems strategic
15:22:57 <Sompi> DuckDuckGo is one of the most used search engines in the world - if not the second most used ...?
15:23:04 <nsITobin> because no one can really confirm anything
15:23:12 <Sompi> And even it is broken like this
15:23:27 <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
15:24:28 <nsITobin> and i tried .19 .20 and wip on windows and linux and its working
15:26:23 <Sompi> Seems that it's been like that for more than one year already
15:26:52 <Sompi> And last three months more consistently
15:26:58 <Sompi> Many users get that error every time
15:27:18 <nsITobin> tho the results i am getting are not using the redirect
15:27:30 <nsITobin> they are direct link save for ad placed ones
15:27:35 <nsITobin> which use a redirect
15:28:05 <nsITobin> y.js?ad_domain=
15:29:58 <nsITobin> OKAY directly going to their redirect thing /l/ does show it as broken on Praxis (Pale Moon) and SeaMonkey..
15:30:46 <nsITobin> Sompi: AND on edge
15:31:36 <Sompi> Yes, it also returns error 400 to wget
15:31:42 <Sompi> So the whole redirect page itself is broken
15:32:00 <Sompi> But for some reason the links only point to that redirect page when I use SeaMonkey's default UA string
15:43:46 <nsITobin> that part i can't reproduce anymore on my end but i did experience it days ago
15:44:06 <nsITobin> but its explained by shards instances and regional delivery and rollout bs
15:44:56 <nsITobin> well its giving 400 no matter what you type in to the l subdir
15:51:19 <nsITobin> --disable-mailnews https://i.ibb.co/mJbQQSG/image.png
15:56:36 <nsITobin> referencing the original bug .. why was NeilAway on about standalone composer
16:00:09 <nsITobin> something just popped into my head.. WHY are we using webapps and not just api endpoints with http transport and local clients?