Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delivery Format: set kn-ingress-format ce extension on imc ingress #8076

Closed
Cali0707 opened this issue Jul 4, 2024 · 5 comments
Closed

Delivery Format: set kn-ingress-format ce extension on imc ingress #8076

Cali0707 opened this issue Jul 4, 2024 · 5 comments
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature-request triage/accepted Issues which should be fixed (post-triage)

Comments

@Cali0707
Copy link
Member

Cali0707 commented Jul 4, 2024

Problem
To support dispatching events from the InMemoryChannel with the correct format when a user sets the spec.delivery.format to ingress, we need to set a cloudevent extension of kn-ingress-format to specify which format was used. This should be set to structured if the input event was structured, and binary if the input event was in binary. However, since this event may have been forwarded from earlier ingress, we need to only set the kn-ingress-format extension if it is not already present on the event.

Persona:
Which persona is this feature for?

Exit Criteria
Unit tests verifying that:

  1. If the extension is not present it is set correctly for both structured and binary events
  2. If the extension is already present, it is not changed for both structured and binary events

Time Estimate (optional):
How many developer-days do you think this may take to resolve? 1-2

Additional context (optional)
Add any other context about the feature request here.

  • The parent issue is: Delivery Format: support specifying the event format #8057
  • The channel ingress handler code is here:
    func (r *EventReceiver) ServeHTTP(response nethttp.ResponseWriter, request *nethttp.Request) {
    ctx := request.Context()
    if r.withContext != nil {
    ctx = r.withContext(ctx)
    }
    response.Header().Set("Allow", "POST, OPTIONS")
    if request.Method == nethttp.MethodOptions {
    response.Header().Set("WebHook-Allowed-Origin", "*") // Accept from any Origin:
    response.Header().Set("WebHook-Allowed-Rate", "*") // Unlimited requests/minute
    response.WriteHeader(nethttp.StatusOK)
    return
    }
    if request.Method != nethttp.MethodPost {
    response.WriteHeader(nethttp.StatusMethodNotAllowed)
    return
    }
    // The response status codes:
    // 202 - the event was sent to subscribers
    // 400 - the request was malformed
    // 404 - the request was for an unknown channel
    // 500 - an error occurred processing the request
    args := ReportArgs{}
    var channel ChannelReference
    var err error
    // prefer using pathToChannelFunc if available
    if r.pathToChannelFunc != nil {
    channel, err = r.pathToChannelFunc(request.URL.Path)
    } else {
    if request.URL.Path != "/" {
    response.WriteHeader(nethttp.StatusBadRequest)
    return
    }
    channel, err = r.hostToChannelFunc(request.Host)
    }
    if err != nil {
    switch err.(type) {
    case UnknownHostError:
    response.WriteHeader(nethttp.StatusNotFound)
    case BadRequestError:
    response.WriteHeader(nethttp.StatusBadRequest)
    default:
    response.WriteHeader(nethttp.StatusInternalServerError)
    }
    r.logger.Info("Could not extract channel", zap.Error(err))
    ReportEventCountMetricsForDispatchError(err, r.reporter, &args)
    return
    }
    r.logger.Debug("Request mapped to channel", zap.String("channel", channel.String()))
    args.Ns = channel.Namespace
    if request.TLS != nil {
    args.EventScheme = "https"
    } else {
    args.EventScheme = "http"
    }
    event, err := http.NewEventFromHTTPRequest(request)
    if err != nil {
    r.logger.Warn("failed to extract event from request", zap.Error(err))
    response.WriteHeader(nethttp.StatusBadRequest)
    _ = r.reporter.ReportEventCount(&args, nethttp.StatusBadRequest)
    return
    }
    // run validation for the extracted event
    if err := event.Validate(); err != nil {
    r.logger.Warn("failed to validate extracted event", zap.Error(err))
    response.WriteHeader(nethttp.StatusBadRequest)
    return
    }
    /// Here we do the OIDC audience verification
    features := feature.FromContext(ctx)
    if features.IsOIDCAuthentication() {
    r.logger.Debug("OIDC authentication is enabled")
    err = r.tokenVerifier.VerifyJWTFromRequest(ctx, request, &r.audience, response)
    if err != nil {
    r.logger.Warn("Error when validating the JWT token in the request", zap.Error(err))
    return
    }
    r.logger.Debug("Request contained a valid JWT. Continuing...")
    }
    err = r.receiverFunc(request.Context(), channel, *event, utils.PassThroughHeaders(request.Header))
    if err != nil {
    if _, ok := err.(*UnknownChannelError); ok {
    response.WriteHeader(nethttp.StatusNotFound)
    } else {
    r.logger.Info("Error in receiver", zap.Error(err))
    response.WriteHeader(nethttp.StatusInternalServerError)
    }
    return
    }
    response.WriteHeader(nethttp.StatusAccepted)
    }
@Cali0707
Copy link
Member Author

Cali0707 commented Jul 4, 2024

/good-first-issue
/triage accepted

Copy link

knative-prow bot commented Jul 4, 2024

@Cali0707:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue
/triage accepted

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-sigs/prow repository.

@knative-prow knative-prow bot added triage/accepted Issues which should be fixed (post-triage) good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Jul 4, 2024
@Cali0707 Cali0707 moved this from Draft to Ready in Eventing Delivery Format Jul 4, 2024
@EraKin575
Copy link
Contributor

/assign

@EraKin575
Copy link
Contributor

/unassign

@Cali0707
Copy link
Member Author

Cali0707 commented Jul 9, 2024

/close

@Cali0707 Cali0707 closed this as completed Jul 9, 2024
@pierDipi pierDipi moved this from Ready to Done in Eventing Delivery Format Jul 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature-request triage/accepted Issues which should be fixed (post-triage)
Projects
Development

No branches or pull requests

2 participants