Bug 211122 - Regression(r259036) Unable to post comments on Jira
Summary: Regression(r259036) Unable to post comments on Jira
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL: https://confluence.atlassian.com/jira...
Keywords: InRadar
Depends on:
Blocks: 209066
  Show dependency treegraph
 
Reported: 2020-04-28 06:20 PDT by Jack Wellborn
Modified: 2020-05-18 08:22 PDT (History)
9 users (show)

See Also:


Attachments
Patch (13.65 KB, patch)
2020-05-01 13:26 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (14.36 KB, patch)
2020-05-01 13:35 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (15.61 KB, patch)
2020-05-01 14:06 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Wellborn 2020-04-28 06:20:09 PDT
Hello,

Safari Technology Preview 105 appears to break commenting on Jira. Safari 13.1 does not have the issue. Attempting to comment yields a the following errors:

[Error] Failed to load resource: the server responded with a status of 403 () (comment, line 0)
[Error] SyntaxError: JSON Parse error: Unexpected identifier "XSRF"
	parse (batch.js:1482:2365)
	error (batch.js:1482:2365)
	c (batch.js:44:22901)
	fireWith (batch.js:44:23654)
	u (batch.js:44:71478)
	(anonymous function) (batch.js:44:75003)
[Error] Failed to load resource: the server responded with a status of 403 () (bulk, line 0)

Browser: Release 105 (Safari 13.2, WebKit 14610.1.10)
OS: Mac OS Mojave 10.15.6
Jira Version: 8.5.0

Thanks

~Jack
Comment 1 Radar WebKit Bug Importer 2020-04-28 17:58:33 PDT
<rdar://problem/62561879>
Comment 2 Maciej Stachowiak 2020-04-29 01:30:28 PDT
Is there a public JIRA instance where this can be observed?
Comment 3 Jack Wellborn 2020-04-29 06:17:55 PDT
Unfortunately, no. This is my work Jira. I can try to debug on my side to see what is specifically causing the error beyond what the console is logging.
Comment 4 Maciej Stachowiak 2020-04-29 22:50:39 PDT
If anyone knows of a public JIRA where the bug also reproduces, it would be tremendously helpful. Meantime, we'll try to reproduce internally.
Comment 5 Jack Wellborn 2020-04-30 07:57:19 PDT
So I tried to do a bit of troubleshooting and it looks like STP 105 is stripping the origin from the POST request used to comment (whereas 13.1 keeps the domain). I am not sure, but it wouldn't surprise me if Jira is checking the origin as part of their validation.
Comment 6 Chris Dumez 2020-04-30 08:02:53 PDT
CC'ing Rob Buis who has been refactoring the FrameLoader recently and Youenn Fablet who is an area expert.
Comment 7 Chris Dumez 2020-04-30 11:00:35 PDT
I am a little suspicious of https://bugs.webkit.org/show_bug.cgi?id=209066 which seems to be recent and in this area.
Comment 8 Chris Dumez 2020-04-30 11:08:08 PDT
https://bugs.webkit.org/show_bug.cgi?id=209066 went into STP 104 though, not 105. Are we certain this regressed in STP 105?
Comment 9 Rob Buis 2020-04-30 11:41:49 PDT
We are following this part of the Fetch specification:
https://fetch.spec.whatwg.org/#origin-header

Is the Origin header for the POST just not there, empty or 'null'?

Is the behavior different on Firefox/Chrome?

Finally, are the url of the page the POST comes from and the destination url same origin? Here protocols (for no-referrer-when-downgrade) are also important, are they both https? And is the page doing the POST setting any referrer policy? TIA!
Comment 10 Jack Wellborn 2020-04-30 11:51:50 PDT
Hi Rob,

STP requests with an origin of null. I haven't checked Chrome or Firefox, but I can tell you that Safari 13.1 populates origin with "https://jira.mycompany.com" (with "mycompany" being the name of my employer.) Furthermore, I can tell you that overriding the origin using Charles proxy resolves the issue. Given that, do you still want me to test other browsers?

~Jack
Comment 11 Chris Dumez 2020-04-30 12:16:33 PDT
I created a test JIRA instance at https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post comments on a JIRA bug with the latest WebKit, without any issue.

What kind of comment are you trying to post? Is it on a bug? Of course, there is always the possibility that the bug only reproduces on hosted instances.
Comment 12 Chris Dumez 2020-04-30 12:19:24 PDT
(In reply to Chris Dumez from comment #11)
> I created a test JIRA instance at
> https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> comments on a JIRA bug with the latest WebKit, without any issue.
> 
> What kind of comment are you trying to post? Is it on a bug? Of course,
> there is always the possibility that the bug only reproduces on hosted
> instances.

Looking at Web Inspector, I do see a POST request when I submit a comment on a JIRA bug:

Request
:method: POST
:scheme: https
:authority: apple-testing.atlassian.net
:path: /rest/api/3/issue/WEB-1/comment
Accept: application/json,text/javascript,*/*
Content-Type: application/json
Origin: https://apple-testing.atlassian.net
Cookie: [MASKED]
Content-Length: 130
Accept-Language: en-us
Host: apple-testing.atlassian.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Referer: https://apple-testing.atlassian.net/browse/WEB-1
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Note that the Origin header looks correct. I am on WebKit r260952.
Comment 13 Chris Dumez 2020-04-30 12:22:53 PDT
(In reply to Chris Dumez from comment #12)
> (In reply to Chris Dumez from comment #11)
> > I created a test JIRA instance at
> > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > comments on a JIRA bug with the latest WebKit, without any issue.
> > 
> > What kind of comment are you trying to post? Is it on a bug? Of course,
> > there is always the possibility that the bug only reproduces on hosted
> > instances.
> 
> Looking at Web Inspector, I do see a POST request when I submit a comment on
> a JIRA bug:
> 
> Request
> :method: POST
> :scheme: https
> :authority: apple-testing.atlassian.net
> :path: /rest/api/3/issue/WEB-1/comment
> Accept: application/json,text/javascript,*/*
> Content-Type: application/json
> Origin: https://apple-testing.atlassian.net
> Cookie: [MASKED]
> Content-Length: 130
> Accept-Language: en-us
> Host: apple-testing.atlassian.net
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> Referer: https://apple-testing.atlassian.net/browse/WEB-1
> Accept-Encoding: gzip, deflate, br
> Connection: keep-alive
> 
> Note that the Origin header looks correct. I am on WebKit r260952.


What does the URL of the wrong POST request look like for you? Is it for the "/comment" one or something else?

I see this other POST request:

Request
:method: POST
:scheme: https
:authority: api.atlassian.com
:path: /metal/ingest
Accept: */*
Content-Type: text/plain;charset=UTF-8
Origin: null
Cookie: [MASKED]
Cache-Control: max-age=0
Accept-Language: en-us
Host: api.atlassian.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
Content-Length: 399
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Where the Origin is null (As explained by Rob earlier, this may be correct behavior, many things are taken into considering to determine what the Origin header should be).
Comment 14 Chris Dumez 2020-04-30 12:42:30 PDT
(In reply to Chris Dumez from comment #13)
> (In reply to Chris Dumez from comment #12)
> > (In reply to Chris Dumez from comment #11)
> > > I created a test JIRA instance at
> > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > 
> > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > there is always the possibility that the bug only reproduces on hosted
> > > instances.
> > 
> > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > a JIRA bug:
> > 
> > Request
> > :method: POST
> > :scheme: https
> > :authority: apple-testing.atlassian.net
> > :path: /rest/api/3/issue/WEB-1/comment
> > Accept: application/json,text/javascript,*/*
> > Content-Type: application/json
> > Origin: https://apple-testing.atlassian.net
> > Cookie: [MASKED]
> > Content-Length: 130
> > Accept-Language: en-us
> > Host: apple-testing.atlassian.net
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > Accept-Encoding: gzip, deflate, br
> > Connection: keep-alive
> > 
> > Note that the Origin header looks correct. I am on WebKit r260952.
> 
> 
> What does the URL of the wrong POST request look like for you? Is it for the
> "/comment" one or something else?
> 
> I see this other POST request:
> 
> Request
> :method: POST
> :scheme: https
> :authority: api.atlassian.com
> :path: /metal/ingest
> Accept: */*
> Content-Type: text/plain;charset=UTF-8
> Origin: null
> Cookie: [MASKED]
> Cache-Control: max-age=0
> Accept-Language: en-us
> Host: api.atlassian.com
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> Content-Length: 399
> Accept-Encoding: gzip, deflate, br
> Connection: keep-alive
> 
> Where the Origin is null (As explained by Rob earlier, this may be correct
> behavior, many things are taken into considering to determine what the
> Origin header should be).

Jack, if you look at the Network Response to the main document, do you see a Referrer-Policy header being served? If so, what is the value for the header?
My JIRA instance does not serve such a header, which could be why I cannot reproduce, especially if I am right that this was caused by Bug 209066.
Comment 15 Rob Buis 2020-04-30 12:52:59 PDT
(In reply to Jack Wellborn from comment #10)
> Hi Rob,
> 
> STP requests with an origin of null. I haven't checked Chrome or Firefox,
> but I can tell you that Safari 13.1 populates origin with
> "https://jira.mycompany.com" (with "mycompany" being the name of my
> employer.) Furthermore, I can tell you that overriding the origin using
> Charles proxy resolves the issue. Given that, do you still want me to test
> other browsers?
> 
> ~Jack

Hi Jack,

Yes, I think those are good things to know. Unfortunately I do not know what you mean by "overriding the origin using Charles proxy", but glad there is a workaround.
Comment 16 Chris Dumez 2020-04-30 13:15:23 PDT
(In reply to Chris Dumez from comment #14)
> (In reply to Chris Dumez from comment #13)
> > (In reply to Chris Dumez from comment #12)
> > > (In reply to Chris Dumez from comment #11)
> > > > I created a test JIRA instance at
> > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > 
> > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > there is always the possibility that the bug only reproduces on hosted
> > > > instances.
> > > 
> > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > a JIRA bug:
> > > 
> > > Request
> > > :method: POST
> > > :scheme: https
> > > :authority: apple-testing.atlassian.net
> > > :path: /rest/api/3/issue/WEB-1/comment
> > > Accept: application/json,text/javascript,*/*
> > > Content-Type: application/json
> > > Origin: https://apple-testing.atlassian.net
> > > Cookie: [MASKED]
> > > Content-Length: 130
> > > Accept-Language: en-us
> > > Host: apple-testing.atlassian.net
> > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > Accept-Encoding: gzip, deflate, br
> > > Connection: keep-alive
> > > 
> > > Note that the Origin header looks correct. I am on WebKit r260952.
> > 
> > 
> > What does the URL of the wrong POST request look like for you? Is it for the
> > "/comment" one or something else?
> > 
> > I see this other POST request:
> > 
> > Request
> > :method: POST
> > :scheme: https
> > :authority: api.atlassian.com
> > :path: /metal/ingest
> > Accept: */*
> > Content-Type: text/plain;charset=UTF-8
> > Origin: null
> > Cookie: [MASKED]
> > Cache-Control: max-age=0
> > Accept-Language: en-us
> > Host: api.atlassian.com
> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > Content-Length: 399
> > Accept-Encoding: gzip, deflate, br
> > Connection: keep-alive
> > 
> > Where the Origin is null (As explained by Rob earlier, this may be correct
> > behavior, many things are taken into considering to determine what the
> > Origin header should be).
> 
> Jack, if you look at the Network Response to the main document, do you see a
> Referrer-Policy header being served? If so, what is the value for the header?
> My JIRA instance does not serve such a header, which could be why I cannot
> reproduce, especially if I am right that this was caused by Bug 209066.

It does not have to be a Referrer-Policy header. It could be a <meta name="referrer" content="XXX"> element in the HTML like documented here:
https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-issues-to-external-websites-972343137.html

It am trying to set this up on my JIRA instance but have not found how yet.
Comment 17 Chris Dumez 2020-04-30 14:19:02 PDT
(In reply to Chris Dumez from comment #16)
> (In reply to Chris Dumez from comment #14)
> > (In reply to Chris Dumez from comment #13)
> > > (In reply to Chris Dumez from comment #12)
> > > > (In reply to Chris Dumez from comment #11)
> > > > > I created a test JIRA instance at
> > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > 
> > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > instances.
> > > > 
> > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > a JIRA bug:
> > > > 
> > > > Request
> > > > :method: POST
> > > > :scheme: https
> > > > :authority: apple-testing.atlassian.net
> > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > Accept: application/json,text/javascript,*/*
> > > > Content-Type: application/json
> > > > Origin: https://apple-testing.atlassian.net
> > > > Cookie: [MASKED]
> > > > Content-Length: 130
> > > > Accept-Language: en-us
> > > > Host: apple-testing.atlassian.net
> > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > Accept-Encoding: gzip, deflate, br
> > > > Connection: keep-alive
> > > > 
> > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > 
> > > 
> > > What does the URL of the wrong POST request look like for you? Is it for the
> > > "/comment" one or something else?
> > > 
> > > I see this other POST request:
> > > 
> > > Request
> > > :method: POST
> > > :scheme: https
> > > :authority: api.atlassian.com
> > > :path: /metal/ingest
> > > Accept: */*
> > > Content-Type: text/plain;charset=UTF-8
> > > Origin: null
> > > Cookie: [MASKED]
> > > Cache-Control: max-age=0
> > > Accept-Language: en-us
> > > Host: api.atlassian.com
> > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > Content-Length: 399
> > > Accept-Encoding: gzip, deflate, br
> > > Connection: keep-alive
> > > 
> > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > behavior, many things are taken into considering to determine what the
> > > Origin header should be).
> > 
> > Jack, if you look at the Network Response to the main document, do you see a
> > Referrer-Policy header being served? If so, what is the value for the header?
> > My JIRA instance does not serve such a header, which could be why I cannot
> > reproduce, especially if I am right that this was caused by Bug 209066.
> 
> It does not have to be a Referrer-Policy header. It could be a <meta
> name="referrer" content="XXX"> element in the HTML like documented here:
> https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> issues-to-external-websites-972343137.html
> 
> It am trying to set this up on my JIRA instance but have not found how yet.

If I add <meta name="referrer" content="no-referrer"> to my JIRA bug tracker's HTML, I indeed see that I can no longer post comments and that the server responds with a 403. Sadly, using <meta name="referrer" content="no-referrer"> is something that is documented by Atlassian at [1]. This used to work but it seems that it no longer does after <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy now not longer causes the Referrer header to be omitted but also the Origin header becomes "null" too. Technically, it looks like r259036 aligns us with the Fetch spec and it does seem like Chrome is planning to implement this too (although it does not appear they have shipped this behavior yet.

I will note that:
a. JIRA does not use <meta name="referrer" content="no-referrer"> by default and it is something the admin added
b. [1] clearly states that "that all the workaround stated in this page are beyond Atlassian Support Offerings."
c. If you use <meta name="referrer" content="same-origin"> then commenting seems to work the the referrer would still get omitted when going to an external site. I do not understand why [1] suggest 'no-referrer', which seems overly aggressive.

[1] https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-issues-to-external-websites-972343137.html
Comment 18 Chris Dumez 2020-04-30 14:19:58 PDT
(In reply to Chris Dumez from comment #17)
> (In reply to Chris Dumez from comment #16)
> > (In reply to Chris Dumez from comment #14)
> > > (In reply to Chris Dumez from comment #13)
> > > > (In reply to Chris Dumez from comment #12)
> > > > > (In reply to Chris Dumez from comment #11)
> > > > > > I created a test JIRA instance at
> > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > 
> > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > instances.
> > > > > 
> > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > a JIRA bug:
> > > > > 
> > > > > Request
> > > > > :method: POST
> > > > > :scheme: https
> > > > > :authority: apple-testing.atlassian.net
> > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > Accept: application/json,text/javascript,*/*
> > > > > Content-Type: application/json
> > > > > Origin: https://apple-testing.atlassian.net
> > > > > Cookie: [MASKED]
> > > > > Content-Length: 130
> > > > > Accept-Language: en-us
> > > > > Host: apple-testing.atlassian.net
> > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > Accept-Encoding: gzip, deflate, br
> > > > > Connection: keep-alive
> > > > > 
> > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > 
> > > > 
> > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > "/comment" one or something else?
> > > > 
> > > > I see this other POST request:
> > > > 
> > > > Request
> > > > :method: POST
> > > > :scheme: https
> > > > :authority: api.atlassian.com
> > > > :path: /metal/ingest
> > > > Accept: */*
> > > > Content-Type: text/plain;charset=UTF-8
> > > > Origin: null
> > > > Cookie: [MASKED]
> > > > Cache-Control: max-age=0
> > > > Accept-Language: en-us
> > > > Host: api.atlassian.com
> > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > Content-Length: 399
> > > > Accept-Encoding: gzip, deflate, br
> > > > Connection: keep-alive
> > > > 
> > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > behavior, many things are taken into considering to determine what the
> > > > Origin header should be).
> > > 
> > > Jack, if you look at the Network Response to the main document, do you see a
> > > Referrer-Policy header being served? If so, what is the value for the header?
> > > My JIRA instance does not serve such a header, which could be why I cannot
> > > reproduce, especially if I am right that this was caused by Bug 209066.
> > 
> > It does not have to be a Referrer-Policy header. It could be a <meta
> > name="referrer" content="XXX"> element in the HTML like documented here:
> > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > issues-to-external-websites-972343137.html
> > 
> > It am trying to set this up on my JIRA instance but have not found how yet.
> 
> If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> tracker's HTML, I indeed see that I can no longer post comments and that the
> server responds with a 403. Sadly, using <meta name="referrer"
> content="no-referrer"> is something that is documented by Atlassian at [1].
> This used to work but it seems that it no longer does after
> <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> now not longer causes the Referrer header to be omitted but also the Origin
> header becomes "null" too. Technically, it looks like r259036 aligns us with
> the Fetch spec and it does seem like Chrome is planning to implement this
> too (although it does not appear they have shipped this behavior yet.
> 
> I will note that:
> a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> and it is something the admin added
> b. [1] clearly states that "that all the workaround stated in this page are
> beyond Atlassian Support Offerings."
> c. If you use <meta name="referrer" content="same-origin"> then commenting
> seems to work the the referrer would still get omitted when going to an
> external site. I do not understand why [1] suggest 'no-referrer', which
> seems overly aggressive.
> 
> [1]
> https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> issues-to-external-websites-972343137.html

Waiting for Jack to confirm my findings.
Comment 19 Jack Wellborn 2020-04-30 17:43:58 PDT
(In reply to Chris Dumez from comment #18)
> (In reply to Chris Dumez from comment #17)
> > (In reply to Chris Dumez from comment #16)
> > > (In reply to Chris Dumez from comment #14)
> > > > (In reply to Chris Dumez from comment #13)
> > > > > (In reply to Chris Dumez from comment #12)
> > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > I created a test JIRA instance at
> > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > 
> > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > instances.
> > > > > > 
> > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > a JIRA bug:
> > > > > > 
> > > > > > Request
> > > > > > :method: POST
> > > > > > :scheme: https
> > > > > > :authority: apple-testing.atlassian.net
> > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > Accept: application/json,text/javascript,*/*
> > > > > > Content-Type: application/json
> > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > Cookie: [MASKED]
> > > > > > Content-Length: 130
> > > > > > Accept-Language: en-us
> > > > > > Host: apple-testing.atlassian.net
> > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > Connection: keep-alive
> > > > > > 
> > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > 
> > > > > 
> > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > "/comment" one or something else?
> > > > > 
> > > > > I see this other POST request:
> > > > > 
> > > > > Request
> > > > > :method: POST
> > > > > :scheme: https
> > > > > :authority: api.atlassian.com
> > > > > :path: /metal/ingest
> > > > > Accept: */*
> > > > > Content-Type: text/plain;charset=UTF-8
> > > > > Origin: null
> > > > > Cookie: [MASKED]
> > > > > Cache-Control: max-age=0
> > > > > Accept-Language: en-us
> > > > > Host: api.atlassian.com
> > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > Content-Length: 399
> > > > > Accept-Encoding: gzip, deflate, br
> > > > > Connection: keep-alive
> > > > > 
> > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > behavior, many things are taken into considering to determine what the
> > > > > Origin header should be).
> > > > 
> > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > 
> > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > issues-to-external-websites-972343137.html
> > > 
> > > It am trying to set this up on my JIRA instance but have not found how yet.
> > 
> > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > tracker's HTML, I indeed see that I can no longer post comments and that the
> > server responds with a 403. Sadly, using <meta name="referrer"
> > content="no-referrer"> is something that is documented by Atlassian at [1].
> > This used to work but it seems that it no longer does after
> > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > now not longer causes the Referrer header to be omitted but also the Origin
> > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > the Fetch spec and it does seem like Chrome is planning to implement this
> > too (although it does not appear they have shipped this behavior yet.
> > 
> > I will note that:
> > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > and it is something the admin added
> > b. [1] clearly states that "that all the workaround stated in this page are
> > beyond Atlassian Support Offerings."
> > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > seems to work the the referrer would still get omitted when going to an
> > external site. I do not understand why [1] suggest 'no-referrer', which
> > seems overly aggressive.
> > 
> > [1]
> > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > issues-to-external-websites-972343137.html
> 
> Waiting for Jack to confirm my findings.

Thanks Chris, 

This aligns with what I am seeing, and I even see the no-referrer meta tag. The question is why does this work with other browsers, including Safari 13.1? Is it possible that these other browsers still allow same-origin referrers?
Comment 20 Jack Wellborn 2020-04-30 17:45:18 PDT
(In reply to Rob Buis from comment #15)
> (In reply to Jack Wellborn from comment #10)
> > Hi Rob,
> > 
> > STP requests with an origin of null. I haven't checked Chrome or Firefox,
> > but I can tell you that Safari 13.1 populates origin with
> > "https://jira.mycompany.com" (with "mycompany" being the name of my
> > employer.) Furthermore, I can tell you that overriding the origin using
> > Charles proxy resolves the issue. Given that, do you still want me to test
> > other browsers?
> > 
> > ~Jack
> 
> Hi Jack,
> 
> Yes, I think those are good things to know. Unfortunately I do not know what
> you mean by "overriding the origin using Charles proxy", but glad there is a
> workaround.

To clarify Charles Proxy is an application that allows developers like me to intercept and modify requests and responses. While it resolves the issue in that I am able to comment while overriding the origin header, it isn't really a fix unfortunately.
Comment 21 Chris Dumez 2020-04-30 17:57:33 PDT
(In reply to Jack Wellborn from comment #19)
> (In reply to Chris Dumez from comment #18)
> > (In reply to Chris Dumez from comment #17)
> > > (In reply to Chris Dumez from comment #16)
> > > > (In reply to Chris Dumez from comment #14)
> > > > > (In reply to Chris Dumez from comment #13)
> > > > > > (In reply to Chris Dumez from comment #12)
> > > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > > I created a test JIRA instance at
> > > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > > 
> > > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > > instances.
> > > > > > > 
> > > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > > a JIRA bug:
> > > > > > > 
> > > > > > > Request
> > > > > > > :method: POST
> > > > > > > :scheme: https
> > > > > > > :authority: apple-testing.atlassian.net
> > > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > > Accept: application/json,text/javascript,*/*
> > > > > > > Content-Type: application/json
> > > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > > Cookie: [MASKED]
> > > > > > > Content-Length: 130
> > > > > > > Accept-Language: en-us
> > > > > > > Host: apple-testing.atlassian.net
> > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > Connection: keep-alive
> > > > > > > 
> > > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > > 
> > > > > > 
> > > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > > "/comment" one or something else?
> > > > > > 
> > > > > > I see this other POST request:
> > > > > > 
> > > > > > Request
> > > > > > :method: POST
> > > > > > :scheme: https
> > > > > > :authority: api.atlassian.com
> > > > > > :path: /metal/ingest
> > > > > > Accept: */*
> > > > > > Content-Type: text/plain;charset=UTF-8
> > > > > > Origin: null
> > > > > > Cookie: [MASKED]
> > > > > > Cache-Control: max-age=0
> > > > > > Accept-Language: en-us
> > > > > > Host: api.atlassian.com
> > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > Content-Length: 399
> > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > Connection: keep-alive
> > > > > > 
> > > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > > behavior, many things are taken into considering to determine what the
> > > > > > Origin header should be).
> > > > > 
> > > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > > 
> > > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > issues-to-external-websites-972343137.html
> > > > 
> > > > It am trying to set this up on my JIRA instance but have not found how yet.
> > > 
> > > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > > tracker's HTML, I indeed see that I can no longer post comments and that the
> > > server responds with a 403. Sadly, using <meta name="referrer"
> > > content="no-referrer"> is something that is documented by Atlassian at [1].
> > > This used to work but it seems that it no longer does after
> > > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > > now not longer causes the Referrer header to be omitted but also the Origin
> > > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > > the Fetch spec and it does seem like Chrome is planning to implement this
> > > too (although it does not appear they have shipped this behavior yet.
> > > 
> > > I will note that:
> > > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > > and it is something the admin added
> > > b. [1] clearly states that "that all the workaround stated in this page are
> > > beyond Atlassian Support Offerings."
> > > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > > seems to work the the referrer would still get omitted when going to an
> > > external site. I do not understand why [1] suggest 'no-referrer', which
> > > seems overly aggressive.
> > > 
> > > [1]
> > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > issues-to-external-websites-972343137.html
> > 
> > Waiting for Jack to confirm my findings.
> 
> Thanks Chris, 
> 
> This aligns with what I am seeing, and I even see the no-referrer meta tag.
> The question is why does this work with other browsers, including Safari
> 13.1? Is it possible that these other browsers still allow same-origin
> referrers?

This is because Rob recently updated WebKit's behavior to align with the Fetch specification, after 13.1 shipped. It appears, based on local testing, that Chrome does not implement this patch of the Fetch specification (yet). Do you know if Chrome intends to implement this behavior? If we're the only ones doing this, it is risky from a compatibility standpoint.
Comment 22 Jack Wellborn 2020-04-30 18:40:51 PDT
(In reply to Chris Dumez from comment #21)
> (In reply to Jack Wellborn from comment #19)
> > (In reply to Chris Dumez from comment #18)
> > > (In reply to Chris Dumez from comment #17)
> > > > (In reply to Chris Dumez from comment #16)
> > > > > (In reply to Chris Dumez from comment #14)
> > > > > > (In reply to Chris Dumez from comment #13)
> > > > > > > (In reply to Chris Dumez from comment #12)
> > > > > > > > (In reply to Chris Dumez from comment #11)
> > > > > > > > > I created a test JIRA instance at
> > > > > > > > > https://apple-testing.atlassian.net/browse/WEB-1. I seem to be able to post
> > > > > > > > > comments on a JIRA bug with the latest WebKit, without any issue.
> > > > > > > > > 
> > > > > > > > > What kind of comment are you trying to post? Is it on a bug? Of course,
> > > > > > > > > there is always the possibility that the bug only reproduces on hosted
> > > > > > > > > instances.
> > > > > > > > 
> > > > > > > > Looking at Web Inspector, I do see a POST request when I submit a comment on
> > > > > > > > a JIRA bug:
> > > > > > > > 
> > > > > > > > Request
> > > > > > > > :method: POST
> > > > > > > > :scheme: https
> > > > > > > > :authority: apple-testing.atlassian.net
> > > > > > > > :path: /rest/api/3/issue/WEB-1/comment
> > > > > > > > Accept: application/json,text/javascript,*/*
> > > > > > > > Content-Type: application/json
> > > > > > > > Origin: https://apple-testing.atlassian.net
> > > > > > > > Cookie: [MASKED]
> > > > > > > > Content-Length: 130
> > > > > > > > Accept-Language: en-us
> > > > > > > > Host: apple-testing.atlassian.net
> > > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > > Referer: https://apple-testing.atlassian.net/browse/WEB-1
> > > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > > Connection: keep-alive
> > > > > > > > 
> > > > > > > > Note that the Origin header looks correct. I am on WebKit r260952.
> > > > > > > 
> > > > > > > 
> > > > > > > What does the URL of the wrong POST request look like for you? Is it for the
> > > > > > > "/comment" one or something else?
> > > > > > > 
> > > > > > > I see this other POST request:
> > > > > > > 
> > > > > > > Request
> > > > > > > :method: POST
> > > > > > > :scheme: https
> > > > > > > :authority: api.atlassian.com
> > > > > > > :path: /metal/ingest
> > > > > > > Accept: */*
> > > > > > > Content-Type: text/plain;charset=UTF-8
> > > > > > > Origin: null
> > > > > > > Cookie: [MASKED]
> > > > > > > Cache-Control: max-age=0
> > > > > > > Accept-Language: en-us
> > > > > > > Host: api.atlassian.com
> > > > > > > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16)
> > > > > > > AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
> > > > > > > Content-Length: 399
> > > > > > > Accept-Encoding: gzip, deflate, br
> > > > > > > Connection: keep-alive
> > > > > > > 
> > > > > > > Where the Origin is null (As explained by Rob earlier, this may be correct
> > > > > > > behavior, many things are taken into considering to determine what the
> > > > > > > Origin header should be).
> > > > > > 
> > > > > > Jack, if you look at the Network Response to the main document, do you see a
> > > > > > Referrer-Policy header being served? If so, what is the value for the header?
> > > > > > My JIRA instance does not serve such a header, which could be why I cannot
> > > > > > reproduce, especially if I am right that this was caused by Bug 209066.
> > > > > 
> > > > > It does not have to be a Referrer-Policy header. It could be a <meta
> > > > > name="referrer" content="XXX"> element in the HTML like documented here:
> > > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > > issues-to-external-websites-972343137.html
> > > > > 
> > > > > It am trying to set this up on my JIRA instance but have not found how yet.
> > > > 
> > > > If I add <meta name="referrer" content="no-referrer"> to my JIRA bug
> > > > tracker's HTML, I indeed see that I can no longer post comments and that the
> > > > server responds with a 403. Sadly, using <meta name="referrer"
> > > > content="no-referrer"> is something that is documented by Atlassian at [1].
> > > > This used to work but it seems that it no longer does after
> > > > <https://trac.webkit.org/changeset/259036> because the 'no-referrer' policy
> > > > now not longer causes the Referrer header to be omitted but also the Origin
> > > > header becomes "null" too. Technically, it looks like r259036 aligns us with
> > > > the Fetch spec and it does seem like Chrome is planning to implement this
> > > > too (although it does not appear they have shipped this behavior yet.
> > > > 
> > > > I will note that:
> > > > a. JIRA does not use <meta name="referrer" content="no-referrer"> by default
> > > > and it is something the admin added
> > > > b. [1] clearly states that "that all the workaround stated in this page are
> > > > beyond Atlassian Support Offerings."
> > > > c. If you use <meta name="referrer" content="same-origin"> then commenting
> > > > seems to work the the referrer would still get omitted when going to an
> > > > external site. I do not understand why [1] suggest 'no-referrer', which
> > > > seems overly aggressive.
> > > > 
> > > > [1]
> > > > https://confluence.atlassian.com/jirakb/how-to-hide-http-referrers-from-
> > > > issues-to-external-websites-972343137.html
> > > 
> > > Waiting for Jack to confirm my findings.
> > 
> > Thanks Chris, 
> > 
> > This aligns with what I am seeing, and I even see the no-referrer meta tag.
> > The question is why does this work with other browsers, including Safari
> > 13.1? Is it possible that these other browsers still allow same-origin
> > referrers?
> 
> This is because Rob recently updated WebKit's behavior to align with the
> Fetch specification, after 13.1 shipped. It appears, based on local testing,
> that Chrome does not implement this patch of the Fetch specification (yet).
> Do you know if Chrome intends to implement this behavior? If we're the only
> ones doing this, it is risky from a compatibility standpoint.

I do not know what Chrome intends to do, but I have implemented a simple reproduction of the issue. The formula is 
<meta name="referrer" content="no-referrer"> + a XMLHttpRequest including withCredentials set to true + a POST request.

Reproduced with origin of null: 
https://jackwellborn.com/playground/XMLHttpRequestOriginNull/noreferrer.html
The data loads, but I suspect I could configure a server to throw an error on the unexpected null origin.

Without the meta tag, the origin is populated: https://jackwellborn.com/playground/XMLHttpRequestOriginNull/referrer.html 

Firefox, Chrome and Safari 13.1 always provide the origin.

I hope this is helpful.
Comment 23 Chris Dumez 2020-05-01 13:26:50 PDT
Created attachment 398228 [details]
Patch
Comment 24 Chris Dumez 2020-05-01 13:35:14 PDT
Created attachment 398229 [details]
Patch
Comment 25 Chris Dumez 2020-05-01 14:06:43 PDT
Created attachment 398236 [details]
Patch
Comment 26 EWS 2020-05-01 16:07:43 PDT
Committed r261036: <https://trac.webkit.org/changeset/261036>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398236 [details].
Comment 27 Jack Wellborn 2020-05-18 07:23:44 PDT
Confirming issue is fixed for me in STP 106. Thanks all!
Comment 28 Chris Dumez 2020-05-18 08:22:40 PDT
(In reply to Jack Wellborn from comment #27)
> Confirming issue is fixed for me in STP 106. Thanks all!

Thank you for verifying.