Closed
Bug 1112796
Opened 9 years ago
Closed 9 years ago
On MDN stage and prod, Access-Control-Allow-Origin is set twice
Categories
(Infrastructure & Operations Graveyard :: WebOps: Community Platform, task)
Infrastructure & Operations Graveyard
WebOps: Community Platform
x86
macOS
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: openjck, Assigned: nmaul)
References
Details
(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/260] [] )
I haven't been able to reproduce this locally. Is there something about the configuration of our stage and production servers that might be causing this? Steps to reproduce: $ curl -I curl -I https://developer.mozilla.org/en-US/docs/Web/HTML/Element/span$json Expected result: Access-Control-Allow-Origin appears once in the output. Actual result: Access-Control-Allow-Origin appears twice in the output.
Comment 1•9 years ago
|
||
You'll see the ACAO header twice on some URLs and once on others. In bug 1043604, you mentioned three URLs: 1. https://developer.mozilla.org/en-US/docs/Web/HTML 2. https://developer.mozilla.org/en-US/ 3. https://developer.mozilla.org/en-US/demos/ At the time, URL #1 had an ACAO header; URLs #2 and #3 did not. Right now, URL #1 has two ACAO headers; URLs #2 and #3 have just one. I think the extra set of headers is coming from a snippet of Apache config from bugs 881315 and 886889. If the double header is causing an issue, I can try explicitly removing that snippet.
Reporter | ||
Comment 2•9 years ago
|
||
The second ACAO is causing an issue for some applications, yeah. If we could try removing that snippet and seeing what affect it has, that would be great!
Comment 3•9 years ago
|
||
Hrm. I discovered that the snippet that I thought was causing the redundancy is *not* present in the staging environment, so I'm back to not being 100% sure where the second instance of it is being set. I went ahead and commented out the stanza that I think is redundant, but I'm going to need to confer with folks to see if I can find where the double header is really coming from.
Reporter | ||
Comment 4•9 years ago
|
||
Hm. We do attempt to set ACAO for some requests at the application level, but I wasn't seeing those apply locally during my testing. If you don't see the header on your end, it could be that the application-level headers are to blame, even though they don't work locally. I'll look into it further tomorrow and will report back.
Comment 5•9 years ago
|
||
in case this hasn't been discussed, there are a couple places where apache configs are shipped within the kuma repo: kuma/configs/htaccess: https://github.com/mozilla/kuma/blob/master/configs/htaccess kuma/etc/apache/all-servers.conf https://github.com/mozilla/kuma/blob/master/etc/apache/all-servers.conf
Comment 6•9 years ago
|
||
A quick question for openjck: Looking at https://github.com/mozilla/kuma/search?utf8=%E2%9C%93&q=Access-Control-Allow-Origin, is it possible that the decorator function is returning the second ACAO header?
Reporter | ||
Comment 7•9 years ago
|
||
Yeah, that's my hunch. I don't see the effects of that decorator locally, but that may be due to another bug.
Whiteboard: [kanban:webops:https://kanbanize.com/ctrl_board/4/1982] → [kanban:https://webops.kanbanize.com/ctrl_board/2/260] []
Assignee | ||
Comment 8•9 years ago
|
||
Is this still happening? I checked the 3 URLs in comment 1, and the URL in comment 0, and they all have exactly 1 instance of the Access-Control-Allow-Origin header. If we can't figure out what's up in the app and/or Apache, we could try having the ZLB strip out all instances of the header and set it just once. A bit of a hack, but might be simpler than hunting forver. Then again, my understanding is MDN is migrating to Cloud Services in the near future, and I expect (but don't know for sure) that this will involve some level of hosting redesign to fit into their environment(s). It may not be worth spending much time on this now.
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(jkarahalis)
Reporter | ||
Comment 9•9 years ago
|
||
Turns out we were setting the header both in our Apache configuration and at the application level. We pushed a temporary fix and started working on a permanent fix in bug 1104260.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(jkarahalis)
Resolution: --- → INVALID
Updated•6 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•