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)

x86
macOS
task
Not set
normal

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.
Blocks: 1104260
Whiteboard: [kanban:webops:https://kanbanize.com/ctrl_board/4/1982]
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.
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!
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.
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.
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
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?
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: server-ops-webops → nmaul
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.
Flags: needinfo?(jkarahalis)
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
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.