Using STN Release 105 (Safari 13.2, WebKit 15610.1.10) on MacOS 10.15.5 Beta (19F83c) I noticed some loading issues using twitter & showing response threads - which this may or may not be caused by this error. However I thought it worth specifically reporting an issue noted when debugging. The following request appears to be issues by the browser: Summary URL: https://api.twitter.com/live_pipeline/events?topic=%2Ftweet_engagement%2F1259892518163972097 Status: — Source: — Request Accept: text/event-stream Cache-Control: no-cache Origin: https://twitter.com Referer: https://twitter.com/TheRealDoctorT/status/1259892518163972097 User-Agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15" Pragma: no-cache Response No response headers Query String Parameters topic: /tweet_engagement/1259892518163972097 The response of STN - as well as safari - is Failed to load resource: FetchEvent.respondWith received an error: TypeError: request header field Pragma is not allowed by Access-Control-Allow-Headers However I do NOT notice these errors in the web tools under firefox, brave, chrome. Further if I try and compose that request in 'postman' I see the request formed as: curl --location --request POST 'https://twitter.com/TheRealDoctorT/status/1259892518163972097' \ --header 'Accept: text/event-stream' \ --header 'Cache-Control: no-cache' \ --header 'Origin: https://twitter.com' \ --header 'Referer: https://twitter.com/TheRealDoctorT/status/1259892518163972097' \ --header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Safari/605.1.15' \ --header 'Pragma: no-cache' \ --header 'Content-Type: application/json' \ --header 'Cookie: _twitter_sess=BAh7CSIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo%250ASGFzaHsABjoKQHVzZWR7ADoPY3JlYXRlZF9hdGwrCAysmwhyAToMY3NyZl9p%250AZCIlNzBmOTI1YzA4OGJlNjdjMjUzNzE0MjA1Y2M5YjcxN2M6B2lkIiVjZGE3%250AZTU5ZmZkZDI1YzdmYTgxZTYwNjhhNmFlZjZhMg%253D%253D--cdb717ebccb83bd97971e4a57daa5e6ceaf1a049; personalization_id="v1_kmuY97VchVluFNvebXMT8Q=="; guest_id=v1%3A158928231937028069; ct0=763d9b79ef3cfde6fa820fe6b96c1c97' \ --data-raw ' {}' I didn't add the cookie and not sure where it came from... it's the closest I can get to what stn is doing. Then I get a valid response ie <!DOCTYPE html> <html dir="ltr" lang="en"> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=0,viewport-fit=cover" /> <link rel="preconnect" href="//abs.twimg.com" /> <link rel="preconnect" href="//api.twitter.com" /> <link rel="preconnect" href="//pbs.twimg.com" /> <link rel="preconnect" href="//t.co" /> <link rel="preconnect" href="//video.twimg.com" /> <link rel="dns-prefetch" href="//abs.twimg.com" /> .... and this continues Is webkit doing something odd to fail this request?
Just to add - Chrome did not appear to send the 'Pragma: no-cache' -- so initially I thought this might be the cause -- yet it is being sent in the postman case
Wondering if it could be due to webkit not supporting wildcards? ie as per https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers
It's difficult to tell, because this doesn't capture Access-Control-Allow-Headers received. Could you please share steps to reproduce the issue? I.e. what URL to open, what to click, whether one needs to be logged in to Twitter for this.
It seems to occur frequently on pretty much any tweet. The example above was from https://twitter.com/TheRealDoctorT/status/1259892518163972097 I'm not sure if it's contributing to twitter not working well loading conversations, but in part that's a twitter issue. This particular failure was just something I noted as 'odd' since the same request appears to feature when using other browsers, where it succeeds (I don't seem to see that pragma being passed though). However I am not a browser/http expert - so hadn't realised that the Access headers received wouldn't be shown.
I wasn't able to reproduce loading issues or getting this error in Console with <https://twitter.com/TheRealDoctorT/status/1259892518163972097>. Importing to Apple's bug tracker to get some more eyes on this.
<rdar://problem/63208957>
I installed build 106 of STN, and this problem appears to no longer occur.
Thank you for the update!