Skip to content

allow setting headers#709

Merged
istio-testing merged 3 commits intoistio:release-1.1from
bevyx:set-headers
Nov 26, 2018
Merged

allow setting headers#709
istio-testing merged 3 commits intoistio:release-1.1from
bevyx:set-headers

Conversation

@itaysk
Copy link
Copy Markdown
Contributor

@itaysk itaysk commented Nov 17, 2018

for #708

@googlebot googlebot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Nov 17, 2018
@istio-testing
Copy link
Copy Markdown
Collaborator

Hi @itaysk. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@rshriram
Copy link
Copy Markdown
Member

..

Copy link
Copy Markdown
Member

@rshriram rshriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..


// HTTP headers to set (overwrite) before forwarding a request to the
// destination service.
map<string, string> set_request_headers = 17;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, I suggest creating a new message like this:

 headers:
   Request:
     Set
     Remove
   Response:
     Set
     Remove

Do you think it’s sufficient to always set, for the most common use case? Append simply buys you the ability to have duplicate headers while common expectation is to set or unset

Copy link
Copy Markdown
Contributor Author

@itaysk itaysk Nov 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

your suggestion makes alot of sense. both the reorg into one spec level field, and to always set by default. But can we eliminate the case for headers with multiple values? (which is allowable by HTTP: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could always have Set, Add, Remove. Something like this:

message HeaderOperations {
  map<string, string> set
  map<string, string> add
  map<string, string> remove
}

message Headers {
  HeaderOperations request
  HeaderOperations response
}

Headers headers

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this is what I meant. I'll make the necessary changes.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rshriram I assume that now append_{request,reqponse}_headers should be marked as deprecated?

Copy link
Copy Markdown
Contributor Author

@itaysk itaysk Nov 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rshriram additionally, doesn't it make sense to nest the messages like:

message Headers {
  HeaderOperations request
  HeaderOperations response

  message HeaderOperations {
    ...
  }
}

WDYT?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep.. go for it.. and please mark the others as deprecated

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rshriram updated based on our discussion

@itaysk
Copy link
Copy Markdown
Contributor Author

itaysk commented Nov 22, 2018

Tests are failing, related to protolock which I'm not entirely familiar with. before committing I ran make generate, did I also need to run make proto-commit or it's taken care of by CI?

@itaysk
Copy link
Copy Markdown
Contributor Author

itaysk commented Nov 24, 2018

OK please disregard my prev message, I did some reading on the build scripts and protolock and now understand I needed to commit the proto.lock file. Pushed the commit and now the build is passing.

@rshriram
Copy link
Copy Markdown
Member

/ok-to-test

@istio-testing istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Nov 25, 2018
@rshriram
Copy link
Copy Markdown
Member

Do you have the implementation ready for this change? If so, I would push this to release-1.1 branch.. If not, then stick with master

@itaysk
Copy link
Copy Markdown
Contributor Author

itaysk commented Nov 25, 2018

Yes I already wrote the core implementation, just need to finalize the auxiliary code like tests. I can have it ready for tomorrow.
(BTW part of the auxiliary included validation where I found another bug: submitted istio/istio#10119 along the way, should I wait for it to be merged? it's a small fix)

@itaysk itaysk changed the base branch from master to release-1.1 November 25, 2018 18:28
@itaysk
Copy link
Copy Markdown
Contributor Author

itaysk commented Nov 25, 2018

changed base to release-1.1

// Apppend the given values to the the headers specified by keys
// (will create a comma seperated list of values)
map<string, string> add = 2;
// Remove a the specified headers
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: a .. "Remove the specified headers"

Copy link
Copy Markdown
Member

@rshriram rshriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@istio-testing
Copy link
Copy Markdown
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: itaysk, rshriram

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants