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