You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Benno Evers <be...@mesosphere.com> on 2018/06/01 15:14:23 UTC

Review Request 67414: Added default message bodies to libprocess HTTP error responses.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/
-----------------------------------------------------------

Review request for mesos.


Repository: mesos


Description
-------

By default on error libprocess would only return a response
with the correct status code and no response body.

However, most browsers do not visually indicate the response
status code, making it hard for the user to figure out what
exactly the problem was.


Diffs
-----

  3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 


Diff: https://reviews.apache.org/r/67414/diff/1/


Testing
-------


Thanks,

Benno Evers


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Mesos Reviewbot Windows <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204191
-----------------------------------------------------------



PASS: Mesos patch 67414 was successfully built and tested.

Reviews applied: `['67414']`

All the build artifacts available at: http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/67414

- Mesos Reviewbot Windows


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Alexander Rukletsov <ru...@gmail.com>.

> On June 5, 2018, 10:46 a.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/http.hpp
> > Line 701 (original), 701-702 (patched)
> > <https://reviews.apache.org/r/67414/diff/1/?file=2034492#file2034492line701>
> >
> >     Why not using `process::http::Status::string()`  https://github.com/apache/mesos/blob/2198b961d24b788564d36490cf52f78d7ec07655/3rdparty/libprocess/src/http.cpp#L176-L180 instead?
> >     
> >     Maybe then you can even put a single line into `Response` c-tor instead of modifying individual classes.
> 
> Benno Evers wrote:
>     I didn't know about this function, but looking at it it seems to be in direct violation of our style guide at (https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables) so we should probably look into deprecating it rather than promoting further usage.
>     
>     But even w/o that issue, I'm not sure that
>     
>     ```
>       BadRequest()
>         : Response(Status::string(Status::BAD_REQUEST), Status::BAD_REQUEST) {}
>     ```
>     
>     is better than
>     
>     ```
>       BadRequest()
>         : Response("400 Bad Request.", Status::BAD_REQUEST) {}
>     ```
>     
>     
>     I dont think putting it in the default constructor of `Response` is a good idea, because we more or less endorse constructing responses like this
>     
>     ```
>       process::http::OK response;
>       response.type = response.PATH;
>       response.path = path;
>       response.headers["Content-Type"] = "application/octet-stream";
>       response.headers["Content-Disposition"] =
>         strings::format("attachment; filename=%s", path).get();
>     ```
>     
>     and we would need to audit all usages of such responses to ensure they're not confused by suddenly having an additional body.
> 
> Alexander Rukletsov wrote:
>     What I don't like about the current approach is the duplication: we already have `code -> string` mapping in http.cpp, it would be good to reuse it here so that they don't go out of sync.
> 
> Benno Evers wrote:
>     I guess I don't really see why it would be a problem if the two go out of sync - many pages have very elaborate 404 error pages including images, animations and lots of text, so I don't think any tool will have the assumption that the response body equals the stringified HTTP status code.

Discussed with Benno offline. I'm convinced that the string does not have to be auto generated, so I'm dropping the issue.


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204313
-----------------------------------------------------------


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-8999
>     https://issues.apache.org/jira/browse/MESOS-8999
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Benno Evers <be...@mesosphere.com>.

> On June 5, 2018, 10:46 a.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/http.hpp
> > Line 701 (original), 701-702 (patched)
> > <https://reviews.apache.org/r/67414/diff/1/?file=2034492#file2034492line701>
> >
> >     Why not using `process::http::Status::string()`  https://github.com/apache/mesos/blob/2198b961d24b788564d36490cf52f78d7ec07655/3rdparty/libprocess/src/http.cpp#L176-L180 instead?
> >     
> >     Maybe then you can even put a single line into `Response` c-tor instead of modifying individual classes.
> 
> Benno Evers wrote:
>     I didn't know about this function, but looking at it it seems to be in direct violation of our style guide at (https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables) so we should probably look into deprecating it rather than promoting further usage.
>     
>     But even w/o that issue, I'm not sure that
>     
>     ```
>       BadRequest()
>         : Response(Status::string(Status::BAD_REQUEST), Status::BAD_REQUEST) {}
>     ```
>     
>     is better than
>     
>     ```
>       BadRequest()
>         : Response("400 Bad Request.", Status::BAD_REQUEST) {}
>     ```
>     
>     
>     I dont think putting it in the default constructor of `Response` is a good idea, because we more or less endorse constructing responses like this
>     
>     ```
>       process::http::OK response;
>       response.type = response.PATH;
>       response.path = path;
>       response.headers["Content-Type"] = "application/octet-stream";
>       response.headers["Content-Disposition"] =
>         strings::format("attachment; filename=%s", path).get();
>     ```
>     
>     and we would need to audit all usages of such responses to ensure they're not confused by suddenly having an additional body.
> 
> Alexander Rukletsov wrote:
>     What I don't like about the current approach is the duplication: we already have `code -> string` mapping in http.cpp, it would be good to reuse it here so that they don't go out of sync.

I guess I don't really see why it would be a problem if the two go out of sync - many pages have very elaborate 404 error pages including images, animations and lots of text, so I don't think any tool will have the assumption that the response body equals the stringified HTTP status code.


- Benno


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204313
-----------------------------------------------------------


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Alexander Rukletsov <ru...@gmail.com>.

> On June 5, 2018, 10:46 a.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/http.hpp
> > Line 701 (original), 701-702 (patched)
> > <https://reviews.apache.org/r/67414/diff/1/?file=2034492#file2034492line701>
> >
> >     Why not using `process::http::Status::string()`  https://github.com/apache/mesos/blob/2198b961d24b788564d36490cf52f78d7ec07655/3rdparty/libprocess/src/http.cpp#L176-L180 instead?
> >     
> >     Maybe then you can even put a single line into `Response` c-tor instead of modifying individual classes.
> 
> Benno Evers wrote:
>     I didn't know about this function, but looking at it it seems to be in direct violation of our style guide at (https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables) so we should probably look into deprecating it rather than promoting further usage.
>     
>     But even w/o that issue, I'm not sure that
>     
>     ```
>       BadRequest()
>         : Response(Status::string(Status::BAD_REQUEST), Status::BAD_REQUEST) {}
>     ```
>     
>     is better than
>     
>     ```
>       BadRequest()
>         : Response("400 Bad Request.", Status::BAD_REQUEST) {}
>     ```
>     
>     
>     I dont think putting it in the default constructor of `Response` is a good idea, because we more or less endorse constructing responses like this
>     
>     ```
>       process::http::OK response;
>       response.type = response.PATH;
>       response.path = path;
>       response.headers["Content-Type"] = "application/octet-stream";
>       response.headers["Content-Disposition"] =
>         strings::format("attachment; filename=%s", path).get();
>     ```
>     
>     and we would need to audit all usages of such responses to ensure they're not confused by suddenly having an additional body.

What I don't like about the current approach is the duplication: we already have `code -> string` mapping in http.cpp, it would be good to reuse it here so that they don't go out of sync.


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204313
-----------------------------------------------------------


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Benno Evers <be...@mesosphere.com>.

> On June 5, 2018, 10:46 a.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/include/process/http.hpp
> > Line 701 (original), 701-702 (patched)
> > <https://reviews.apache.org/r/67414/diff/1/?file=2034492#file2034492line701>
> >
> >     Why not using `process::http::Status::string()`  https://github.com/apache/mesos/blob/2198b961d24b788564d36490cf52f78d7ec07655/3rdparty/libprocess/src/http.cpp#L176-L180 instead?
> >     
> >     Maybe then you can even put a single line into `Response` c-tor instead of modifying individual classes.

I didn't know about this function, but looking at it it seems to be in direct violation of our style guide at (https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables) so we should probably look into deprecating it rather than promoting further usage.

But even w/o that issue, I'm not sure that

```
  BadRequest()
    : Response(Status::string(Status::BAD_REQUEST), Status::BAD_REQUEST) {}
```

is better than

```
  BadRequest()
    : Response("400 Bad Request.", Status::BAD_REQUEST) {}
```


I dont think putting it in the default constructor of `Response` is a good idea, because we more or less endorse constructing responses like this

```
  process::http::OK response;
  response.type = response.PATH;
  response.path = path;
  response.headers["Content-Type"] = "application/octet-stream";
  response.headers["Content-Disposition"] =
    strings::format("attachment; filename=%s", path).get();
```

and we would need to audit all usages of such responses to ensure they're not confused by suddenly having an additional body.


- Benno


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204313
-----------------------------------------------------------


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204313
-----------------------------------------------------------




3rdparty/libprocess/include/process/http.hpp
Line 701 (original), 701-702 (patched)
<https://reviews.apache.org/r/67414/#comment286735>

    Why not using `process::http::Status::string()`  https://github.com/apache/mesos/blob/2198b961d24b788564d36490cf52f78d7ec07655/3rdparty/libprocess/src/http.cpp#L176-L180 instead?
    
    Maybe then you can even put a single line into `Response` c-tor instead of modifying individual classes.


- Alexander Rukletsov


On June 1, 2018, 3:14 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 3:14 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Mesos Reviewbot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review204215
-----------------------------------------------------------



Bad review!

Reviews applied: []

Error:
No reviewers specified. Please find a reviewer by asking on JIRA or the mailing list.

- Mesos Reviewbot


On June 1, 2018, 8:14 a.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated June 1, 2018, 8:14 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 055447e13117c0a3ba79d0fc326ece657e8f064f 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Alexander Rukletsov <ru...@gmail.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review209290
-----------------------------------------------------------


Fix it, then Ship it!




Thanks! I'll fix the outstanding issues and commit shorty.


3rdparty/libprocess/include/process/http.hpp
Lines 778-779 (original), 778-779 (patched)
<https://reviews.apache.org/r/67414/#comment293581>

    It makes sense to add the same text here, right?



3rdparty/libprocess/include/process/http.hpp
Lines 820-831 (original), 824-838 (patched)
<https://reviews.apache.org/r/67414/#comment293580>

    Even though both are apparently allowed by our style guide, I'd go for local consistency.


- Alexander Rukletsov


On Oct. 5, 2018, 4:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated Oct. 5, 2018, 4:45 p.m.)
> 
> 
> Review request for mesos and Alexander Rukletsov.
> 
> 
> Bugs: MESOS-8999
>     https://issues.apache.org/jira/browse/MESOS-8999
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> A rudimentary text-only body is added to the default body of HTTP
> error responses, mirroring the approach taken by e.g. the Go
> standard library or Python's http.server module.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp fa66b0fe2ed72e218b235ac4b697a2a294027527 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/2/
> 
> 
> Testing
> -------
> 
> Started `make check` on various different platforms (Run #4563)
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Mesos Reviewbot Windows <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review209274
-----------------------------------------------------------



PASS: Mesos patch 67414 was successfully built and tested.

Reviews applied: `['67414']`

All the build artifacts available at: http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/2427/mesos-review-67414

- Mesos Reviewbot Windows


On Oct. 5, 2018, 4:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated Oct. 5, 2018, 4:45 p.m.)
> 
> 
> Review request for mesos and Alexander Rukletsov.
> 
> 
> Bugs: MESOS-8999
>     https://issues.apache.org/jira/browse/MESOS-8999
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> A rudimentary text-only body is added to the default body of HTTP
> error responses, mirroring the approach taken by e.g. the Go
> standard library or Python's http.server module.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp fa66b0fe2ed72e218b235ac4b697a2a294027527 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/2/
> 
> 
> Testing
> -------
> 
> Started `make check` on various different platforms (Run #4563)
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Mesos Reviewbot <re...@mesos.apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/#review209280
-----------------------------------------------------------



Bad patch!

Reviews applied: [67414]

Failed command: python support/apply-reviews.py -n -r 67414

Error:
Traceback (most recent call last):
  File "support/apply-reviews.py", line 35, in <module>
    import urllib.request
ImportError: No module named request

Full log: https://builds.apache.org/job/Mesos-Reviewbot/23456/console

- Mesos Reviewbot


On Oct. 5, 2018, 4:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67414/
> -----------------------------------------------------------
> 
> (Updated Oct. 5, 2018, 4:45 p.m.)
> 
> 
> Review request for mesos and Alexander Rukletsov.
> 
> 
> Bugs: MESOS-8999
>     https://issues.apache.org/jira/browse/MESOS-8999
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> By default on error libprocess would only return a response
> with the correct status code and no response body.
> 
> However, most browsers do not visually indicate the response
> status code, making it hard for the user to figure out what
> exactly the problem was.
> 
> A rudimentary text-only body is added to the default body of HTTP
> error responses, mirroring the approach taken by e.g. the Go
> standard library or Python's http.server module.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp fa66b0fe2ed72e218b235ac4b697a2a294027527 
> 
> 
> Diff: https://reviews.apache.org/r/67414/diff/2/
> 
> 
> Testing
> -------
> 
> Started `make check` on various different platforms (Run #4563)
> 
> 
> Thanks,
> 
> Benno Evers
> 
>


Re: Review Request 67414: Added default message bodies to libprocess HTTP error responses.

Posted by Benno Evers <be...@mesosphere.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67414/
-----------------------------------------------------------

(Updated Oct. 5, 2018, 4:45 p.m.)


Review request for mesos and Alexander Rukletsov.


Changes
-------

Rebased onto latest master and applied `clang-format` on the lines changed in this patch.


Bugs: MESOS-8999
    https://issues.apache.org/jira/browse/MESOS-8999


Repository: mesos


Description (updated)
-------

By default on error libprocess would only return a response
with the correct status code and no response body.

However, most browsers do not visually indicate the response
status code, making it hard for the user to figure out what
exactly the problem was.

A rudimentary text-only body is added to the default body of HTTP
error responses, mirroring the approach taken by e.g. the Go
standard library or Python's http.server module.


Diffs (updated)
-----

  3rdparty/libprocess/include/process/http.hpp fa66b0fe2ed72e218b235ac4b697a2a294027527 


Diff: https://reviews.apache.org/r/67414/diff/2/

Changes: https://reviews.apache.org/r/67414/diff/1-2/


Testing (updated)
-------

Started `make check` on various different platforms (Run #4563)


Thanks,

Benno Evers