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?