Skip to content
GitLab
    • Explore Projects Groups Snippets
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • N node-http-proxy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 482
    • Issues 482
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 102
    • Merge requests 102
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • http ... PARTY!
  • node-http-proxy
  • Merge requests
  • !356
An error occurred while fetching the assigned milestone of the selected merge_request.

Extend emitted events to accommodate caching layer

  • Review changes

  • Download
  • Email patches
  • Plain diff
Administrator requested to merge github/fork/colinmollenhour/patch-1 into master 12 years ago
  • Overview 8
  • Commits 3
  • Pipelines 0
  • Changes 1

Created by: colinmollenhour

I am implementing a caching layer on top of http-proxy and without these changes see no good way to intercept the upstream response so that it can be stored in a cache or replace a 304 response with a 200 response or manipulate headers in a few places. None of these changes will break backwards compatibility.

Note, the caching proxy layer is fully implemented but is still in beta: colinmollenhour/node-caching-proxy

Approval is optional

Merge details

  • 1 commit and 1 merge commit will be added to master.
  • Source branch will not be deleted.

Activity


  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: indexzero

    This seems reasonable.

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: colinmollenhour

    Just added another commit. This is the last change I need to be able to add the caching layer. With this change I can replace a 304 response with a 200 response and I can filter headers which are not meant for the client.

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: indexzero

    @colinmollenhour Can you add tests for this?

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: colinmollenhour

    None of the tests use the arguments from the request 'end' event so no changes needed. Do you want a test that confirms that the new argument exists?

    The second block of code has no effect unless there is an event observer for the proxyResponse event and that observer throws an exception. So I'm not sure how to add a test specifically for this since the outcome on an observer that does nothing is the same as no observer and the tests should not predict what the observer will do or not do. Basically if there is an observer it is up to the author of that observer to test the outcome, right?

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: indexzero

    Cherry-picked. Thanks.

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: colinmollenhour

    Thanks, Charlie!

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: Giuliano84

    Hi @colinmollenhour, @indexzero

    I'm trying to leverage proxyResponse event to modify response headers that get setted up by the proxied server. This means that the server behind the proxy put some data in an "x-cust-field" on the res object so and Proxy can read and process it on proxyResponse. Now I dont want this info to be sent to the client, options are: removing the field or just edit it removing sensible data.

    proxy.on('proxyResponse', function (req, res, response) {
    
      res.setHeader('x-new-cust-field', 'mycustomfield');    //Able to add custom headers fields
      res.setHeader('x-cust-field', 'editedcustomfield');    //This makes no changes in the response header
    
      //maybe I can intercept it on some response emitted events?
      response.on('data', function(body){
        try {
    
          res.getHeader('x-cust-field') //can see all the values written by proxied server 
          res.setHeader('x-cust-field', 'editedcustomfield');    //Can't set headers after they are sent.
    
        } catch(e){
          //ERROR
        }
      })
    });

    I'm not sure if I should act on res or response (the latter has no setHeader methods), this seems possible so what am I missing? Thanks

  • Administrator
    Administrator @root · 12 years ago
    Author Contributor

    Created by: colinmollenhour

    res is the response to the client, response is the response from upstream. however, it has been a while since I looked at this code so I don't know offhand if it is sufficient to use res.setHeader. You might need to remove the header from response instead..

Please register or sign in to reply
0 Assignees
None
Assign to
0 Reviewers
None
Request review from
Labels
0
None
0
None
    Assign labels
  • Manage project labels

Milestone
No milestone
None
None
Time tracking
No estimate or time spent
Lock merge request
Unlocked
0
0 participants
Reference:
Source branch: github/fork/colinmollenhour/patch-1

Menu

Explore Projects Groups Snippets