trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zwoop <...@git.apache.org>
Subject [GitHub] trafficserver pull request #772: TS-3726: Expose build_error_response
Date Sat, 02 Jul 2016 15:51:20 GMT
Github user zwoop commented on a diff in the pull request:

    https://github.com/apache/trafficserver/pull/772#discussion_r69379523
  
    --- Diff: proxy/api/ts/ts.h ---
    @@ -2336,6 +2336,35 @@ tsapi uint64_t TSHttpTxnIdGet(TSHttpTxn txnp);
     tsapi TSReturnCode TSBase64Decode(const char *str, size_t str_len, unsigned char *dst,
size_t dst_size, size_t *length);
     tsapi TSReturnCode TSBase64Encode(const char *str, size_t str_len, char *dst, size_t
dst_size, size_t *length);
     
    +/* Expose internal build_error_response function */
    +/**
    +   This method sets the requires state for an error reply, including
    +   the error text, status code, reason phrase, and reply headers.
    +
    +   The caller calls the method with the TSHttpTxn <txnp>, the
    +   HTTP status code <status_code>, a user-specified reason phrase
    +   string (or NULL) <reason_phrase_or_null>, and a printf-like
    +   text format and arguments which are appended to the error text.
    +
    +   @param txnp the transaction pointer
    +   @param status_code the HTTP status code
    +   @param reason_phrase_or_null a user-specified reason phrase string. If it
    +          is NULL, the default HTTP reason phrase is used.
    +   @param error_body_type the error message type, as specified by the HttpBodyFactory
    +          customized error page system. Get the list by command:
    +             "ls -al etc/trafficserver/body_factory/default/"
    +
    +   @param format If it is not NULL or "", it is also added to the error text 
    +          body as descriptive text in the error body.
    +
    +   @note reference from build_error_response: 
    +         This routine DOES NOT check for buffer overflows.  The caller should keep
    --- End diff --
    
    I agree. My thoughts was that we'd first cleanup the underlying body factory code (separate
Jira's for that), such that we get clean and efficient APIs. And then we add public plugin
APIs on top of that
    
    So, I agree that for now, we probably shouldn't commit this, but once you (Jari) are done
with the body factory changes, you can perhaps work with Oknet on getting this merged?
    
    I hope that make sense?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message