Hello, Bug is fixed in nightly build (use jenkins last build), if reported can give us some feedback, it would be nice.
Thanks On Mon, Oct 16, 2017 at 10:12 PM, Epp, J Wyatt <[email protected]> wrote: > > -----Original Message----- > > From: Philippe Mouawad [mailto:[email protected]] > > Sent: Wednesday, 11 October, 2017 14:45 > > To: [email protected] > > Subject: Re: Bug 60190 - Content-Type is added for POST unconditionally > > > > Hello > > Any feedback on this ? > > Sorry, been working on other things and haven't been following the list > closely. > > > On Fri, Sep 8, 2017 at 2:12 PM, Philippe Mouawad < > > [email protected]> wrote: > > > >> Hello, > >> How about not adding this anymore if not set and having a property that > >> allows to do that ? > >> > >> - post_add_content_type_if_missing=false > > If I read you correctly, the idea is to default to _not_ adding a default > content-type, but leave the option? That seems fine. As the OP for this > bug, I would certainly like to see it fixed; it creates some annoying > special cases for us. Even setting aside our self-interest, from a design > standpoint, it violates the principle of least astonishment: there's no > indication anywhere that this behaviour exists, which makes debugging > problems caused by it rather tricky. > > The way I see it, if you're recording, it should _always_ record, > verbatim, exactly the traffic that passes between the client and server. > The real world sucks and browsers don't always do what they "SHOULD"; no > need to confuse the issue further. > > >> What is the risk ? > > Honestly, I'd be a bit surprised to find anything relying on this > behaviour. As you note from the spec, the default lowering should be to > "application/octet-stream", not "application/x-www-form-urlencoded", so > anyone looking for that type should have no reasonable expectation that > they'll find it. > > Cheers, > Wyatt > > Confidentiality Notice: This electronic message transmission, including > any attachment(s), may contain confidential, proprietary, or privileged > information from Chemical Abstracts Service ("CAS"), a division of the > American Chemical Society ("ACS"). If you have received this transmission > in error, be advised that any disclosure, copying, distribution, or use of > the contents of this information is strictly prohibited. Please destroy all > copies of the message and contact the sender immediately by either replying > to this message or calling 614-447-3600. > > -- Cordialement. Philippe Mouawad.
