third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post-expected.txt - Issue 2225383003: Origin header should be preserved in http requests made via OpenURL code path.

Side by Side Diff: third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post-expected.txt

Issue 2225383003: Origin header should be preserved in http requests made via OpenURL code path. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Created 4 years, 4 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post.html ('K') | « third_party/WebKit/LayoutTests/http/tests/navigation/form-targets-cross-site-frame-post.html ('k') | third_party/WebKit/LayoutTests/http/tests/navigation/post-basic-expected.txt » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 Test field:	1 Test field:

2	2

3	3

4 --------	4 --------

5 Frame: 'cross-site-frame'	5 Frame: 'cross-site-frame'

6 --------	6 --------

7 This page was requested with the HTTP method POST.	7 This page was requested with the HTTP method POST.

8	8

9 Parameters:	9 Parameters:

10	10

11 test-field = test-value	11 test-field = test-value

	12 Http headers:

	13

	14 HTTP_CACHE_CONTROL = max-age=0

	15 HTTP_CONNECTION = keep-alive

	16 HTTP_HOST = localhost:8000

	17 HTTP_ORIGIN = http://127.0.0.1:8000
	Łukasz Anforowicz 2016/08/09 17:55:51 1. When this test with --site-per-process flag, we 1. When this test with --site-per-process flag, we get HTTP_ORIGIN = null - this is obviously wrong. 2. Http response doesn't include Access-Control-Allow-Origin header, so it is a bit surprising that the request succeeds (see also https://crbug.com/635400#c13) jww 2016/08/09 22:38:22 I'm not sure what's going on, but it is not "obvio Show quoted text On 2016/08/09 17:55:51, Łukasz (OOO until Aug the 8th) wrote: > 1. When this test with --site-per-process flag, we get HTTP_ORIGIN = null - this > is obviously wrong. I'm not sure what's going on, but it is not "obviously wrong" to me. The Origin header spec is very clear that any "privacy sensitive" contexts should set the header to 'null' and it leaves "privacy sensitive" contexts up to the user agent to define. I agree, though, that it feels weird. Show quoted text > > 2. Http response doesn't include Access-Control-Allow-Origin header, so it is a > bit surprising that the request succeeds (see also https://crbug.com/635400#c13) Łukasz Anforowicz 2016/08/10 00:03:19 The "obviously wrong" part is that behavior should Show quoted text On 2016/08/09 22:38:22, jww wrote: > On 2016/08/09 17:55:51, Łukasz (OOO until Aug the 8th) wrote: > > 1. When this test with --site-per-process flag, we get HTTP_ORIGIN = null - > this > > is obviously wrong. > I'm not sure what's going on, but it is not "obviously wrong" to me. The Origin > header spec is very clear that any "privacy sensitive" contexts should set the > header to 'null' and it leaves "privacy sensitive" contexts up to the user agent > to define. I agree, though, that it feels weird. The "obviously wrong" part is that behavior shouldn't be different between OOPIFs (i.e. --site-per-process mode) and regular/default mode. If Origin=null was desirable, then we should be also using it without --site-per-process. AFAICT using the real (i.e. non-null) Origin is okay in this scenario. Show quoted text > > 2. Http response doesn't include Access-Control-Allow-Origin header, so it is > a > > bit surprising that the request succeeds (see also > https://crbug.com/635400#c13) > I guess I learned today that Origin header might be used outside of CORS protocol and in this case lack of Access-Control-Allow-Origin http response header shouldn't trigger a failure. Is this correct? jww 2016/08/10 00:44:53 Ah, yes, agreed. Show quoted text On 2016/08/10 00:03:19, Łukasz Anforowicz wrote: > On 2016/08/09 22:38:22, jww wrote: > > On 2016/08/09 17:55:51, Łukasz (OOO until Aug the 8th) wrote: > > > 1. When this test with --site-per-process flag, we get HTTP_ORIGIN = null - > > this > > > is obviously wrong. > > I'm not sure what's going on, but it is not "obviously wrong" to me. The > Origin > > header spec is very clear that any "privacy sensitive" contexts should set the > > header to 'null' and it leaves "privacy sensitive" contexts up to the user > agent > > to define. I agree, though, that it feels weird. > > The "obviously wrong" part is that behavior shouldn't be different between > OOPIFs (i.e. --site-per-process mode) and regular/default mode. If Origin=null > was desirable, then we should be also using it without --site-per-process. > AFAICT using the real (i.e. non-null) Origin is okay in this scenario. Ah, yes, agreed. Show quoted text > > > > 2. Http response doesn't include Access-Control-Allow-Origin header, so it > is > > a > > > bit surprising that the request succeeds (see also > > https://crbug.com/635400#c13) > > > > I guess I learned today that Origin header might be used outside of CORS > protocol and in this case lack of Access-Control-Allow-Origin http response > header shouldn't trigger a failure. Is this correct? Yup!
	18 HTTP_REFERER = http://127.0.0.1:8000/navigation/form-targets-cross-site-frame-po st.html
	Łukasz Anforowicz 2016/08/09 17:55:51 It is interesting that Origin header above provide It is interesting that Origin header above provides a subset of information already provided by the Referer header. jww 2016/08/09 22:38:22 Why is that surprising? One of the goals of the Or Show quoted text On 2016/08/09 17:55:51, Łukasz (OOO until Aug the 8th) wrote: > It is interesting that Origin header above provides a subset of information > already provided by the Referer header. Why is that surprising? One of the goals of the Origin header is to allow you to strip the privacy-invasive Referer header (which, for example, some firewalls will do) while still keeping the Origin information. Łukasz Anforowicz 2016/08/10 00:03:19 Thanks for the explanation. TIL :-) Show quoted text On 2016/08/09 22:38:22, jww wrote: > On 2016/08/09 17:55:51, Łukasz (OOO until Aug the 8th) wrote: > > It is interesting that Origin header above provides a subset of information > > already provided by the Referer header. > > Why is that surprising? One of the goals of the Origin header is to allow you to > strip the privacy-invasive Referer header (which, for example, some firewalls > will do) while still keeping the Origin information. Thanks for the explanation. TIL :-)
	19 HTTP_UPGRADE_INSECURE_REQUESTS = 1

OLD	NEW