Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 22900200C8C for ; Tue, 6 Jun 2017 17:23:23 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 1B7D2160BD4; Tue, 6 Jun 2017 15:23:23 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 6B476160BC3 for ; Tue, 6 Jun 2017 17:23:22 +0200 (CEST) Received: (qmail 19519 invoked by uid 500); 6 Jun 2017 15:23:21 -0000 Mailing-List: contact issues-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mesos.apache.org Delivered-To: mailing list issues@mesos.apache.org Received: (qmail 19492 invoked by uid 99); 6 Jun 2017 15:23:20 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jun 2017 15:23:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4555B1A093E for ; Tue, 6 Jun 2017 15:23:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id p2W8sx67_4yJ for ; Tue, 6 Jun 2017 15:23:19 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 4322D5FDB7 for ; Tue, 6 Jun 2017 15:23:19 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CF7DDE0D5C for ; Tue, 6 Jun 2017 15:23:18 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3799A21E0F for ; Tue, 6 Jun 2017 15:23:18 +0000 (UTC) Date: Tue, 6 Jun 2017 15:23:18 +0000 (UTC) From: "Greg Mann (JIRA)" To: issues@mesos.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (MESOS-7629) Parsing to protobuf leads to API call validation errors MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 06 Jun 2017 15:23:23 -0000 [ https://issues.apache.org/jira/browse/MESOS-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039076#comment-16039076 ] Greg Mann commented on MESOS-7629: ---------------------------------- cc [~bmahler] > Parsing to protobuf leads to API call validation errors > ------------------------------------------------------- > > Key: MESOS-7629 > URL: https://issues.apache.org/jira/browse/MESOS-7629 > Project: Mesos > Issue Type: Bug > Components: stout > Reporter: Greg Mann > Labels: api, json, mesosphere, parsing, protobuf > > The {{::protobuf::parse()}} function will [silently drop unrecognized fields|https://github.com/apache/mesos/blob/7ec3269d51d7d180aa857140097c170c469d7959/3rdparty/stout/include/stout/protobuf.hpp#L589], which makes sense in the context of maintaining backward-compatibility across different Mesos versions which may add or remove fields from protobuf messages. However, since we [rely on this protobuf parsing|https://github.com/apache/mesos/blob/7ec3269d51d7d180aa857140097c170c469d7959/src/master/http.cpp#L514-L520] in some places for validation of user-supplied JSON, this can lead to API endpoints returning successful 2XX responses, when in fact the JSON was malformed and the call has not been completed as submitted. > We should consider adding a parameter to API calls which allows users to enable/disable ignoring unrecognized fields in the call. If the default behavior for JSON requests was to return an error rather than ignore unrecognized fields, then our parsing code would catch malformed JSON submissions. The user could opt-in to the "ignore unrecognized fields" behavior when backwards compatibility is a concern. -- This message was sent by Atlassian JIRA (v6.3.15#6346)