0

My app was sending request with header field "Content type" [sic] and value "form-data" [sic] to the server. Although it seems wrong - it seems it was causing no problem until couple of days ago. Then something happened (admin installed security update or so) and now the lamp server returns 400 bad request, which is what one would expect.

While I could update the app to send proper header values but I'm not allowed to due to client's requirement - and I need to be able to revert / accept the bad request as it was working before.

With any other server it seems it would work fine - but on my server and local machine - the app now gets 400 bad request returned.

Any idea how I could make this work? I think the server admin installed some security update and this problem appeared but I don't seem to be able to revert it in any way. Even creating a new server isn't solving it.

I've seen some module 'mod_headers' for apache which I think might be able to allow me to accept a custom malformed header "Content type" but not sure if that is the way to go.

This is all that I'm getting in my local machines server log (screenshot of access log):

enter image description here

Pierre.Vriens
  • 1,159
  • 34
  • 15
  • 19
Tom
  • 103
  • 5
  • whos the client? The server owner? – JIV May 12 '17 at 13:08
  • @JIV excuse me for the poorly worded description. i developed the app for a client. i own the server. client doesn't want/can't update the app due to his own reasons. so i need the existing app with malformed request to work with the server like it was working before. i can make any/all changes to the server, not the app. – Tom May 12 '17 at 16:58

1 Answers1

0

Why can't you conform to standards?

RFC 7230, HTTP/1.1 Message Syntax and Routing, section 3.2:

3.2. Header Fields

Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace.

 header-field   = `field-name ":" OWS field-value OWS`

If it was working, it was wrong. Update your app to use standard HTTP/1.1 Content-Type: type/subtype header providing a standard MIME type, instead. Then, you don't need any workarounds or hacks to get your web server work against standards.

Community
  • 1
Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122