You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2017/09/08 12:12:29 UTC
Bug 60190 - Content-Type is added for POST unconditionally
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
What is the risk ?
As per:
- https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and only
if the media type is not given by a Content-Type field, the recipient MAY
attempt to guess the media type via inspection of its content and/or the
name extension(s) of the URI used to identify the resource. If the media
type remains unknown, the recipient SHOULD treat it as type
"application/octet-stream".
--
Regards.
Philippe
Re: Bug 60190 - Content-Type is added for POST unconditionally
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <je...@cas.org> wrote:
> > -----Original Message-----
> > From: Philippe Mouawad [mailto:p.mouawad@ubik-ingenierie.com]
> > Sent: Wednesday, 11 October, 2017 14:45
> > To: dev@jmeter.apache.org
> > 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 <
> > p.mouawad@ubik-ingenierie.com> 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.
RE: Bug 60190 - Content-Type is added for POST unconditionally
Posted by "Epp, J Wyatt" <je...@cas.org>.
> -----Original Message-----
> From: Philippe Mouawad [mailto:p.mouawad@ubik-ingenierie.com]
> Sent: Wednesday, 11 October, 2017 14:45
> To: dev@jmeter.apache.org
> 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 <
> p.mouawad@ubik-ingenierie.com> 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.
Re: Bug 60190 - Content-Type is added for POST unconditionally
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello
Any feedback on this ?
Thanks
On Fri, Sep 8, 2017 at 2:12 PM, Philippe Mouawad <
p.mouawad@ubik-ingenierie.com> 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
>
>
> What is the risk ?
>
> As per:
>
> - https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html
>
> Any HTTP/1.1 message containing an entity-body SHOULD include a
> Content-Type header field defining the media type of that body. If and only
> if the media type is not given by a Content-Type field, the recipient MAY
> attempt to guess the media type via inspection of its content and/or the
> name extension(s) of the URI used to identify the resource. If the media
> type remains unknown, the recipient SHOULD treat it as type
> "application/octet-stream".
>
>
> --
> Regards.
> Philippe
>
>
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie
UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/>
UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack>