April 2016 - Wine-Devel - list.winehq.org

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

by Theodore Dubois

I know Crossover uses a custom loader for app bundles, have there been any problems there? ~Theodore > On Apr 26, 2016, at 1:35 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > > I have both a custom wine loader and a hacked version of Wine, so I just reverted the patch. > > It would be really nice to have this work for when I’m not using a custom loader. Maybe you could check if argv is in the malloc heap? Or maybe I could somehow indicate when calling wine_init that the argv is malloced? > > ~Theodore > >> On Apr 26, 2016, at 1:02 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: >> >> Sorry it took me so long to respond. >> >> What this actually does is it changes the ps output so that the wine binary doesn't show up in the command line. Naturally, it relies on the argv block being one huge null-null-terminated list of strings (as most UNIX-like systems do, apparently). If you're not building your argv this way, then yes, wine will crash. Also, if wine's idea of the argv block isn't the one that the OS gave to main(), the ps output won't be affected. >> >> The code that manipulates the argv block existed in the Linux case. I surmise, then, that we'd have this same problem there. >> >> I'd kinda like to keep it, but then we'd need some way to detect that the argv we have isn't the block that was passed to main(), or isn't a null-null-terminated string list. (Or, maybe I can use _NSGetArgv() on Mac OS... but then all the other systems we support will still have this problem, and since you've written your own loader, we can't really rely on the order of arguments being "wine" "program" "...".) If you'd like me to just gut that piece of code, I'll be happy to write a patch to do that. >> >> Chip >> >> >> On Wed, Apr 6, 2016 at 4:03 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> I CC’d him on the original email. >> >> It would be neat if the wine program name could show up in Activity Monitor on OSX, so I can tell one wine process apart from another. There is a way to do it (http://stackoverflow.com/questions/4217947/setting-process-name-on-mac-os-x…) but it requires undocumented APIs. (Damn.) >> >> ~Theodore >> >>> On Apr 6, 2016, at 3:35 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >>> >>> Ah, I see. Yeah, that's weird. Have you tried asking Chip directly? I'm CC'ing him. >>> >>> -Ken >>> >>>> On Apr 6, 2016, at 4:53 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >>>> >>>> Yes, I did. The problem is that the code assumes that argv[0] - argv[1] (= offset) is a meaningful quantity, which it isn’t because each string in the argv array came from strdup. >>>> >>>> ~Theodore >>>> >>>>> On Apr 6, 2016, at 2:14 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >>>>> >>>>> Did you allocate one more entry in your argv than is needed for actual arguments and put a terminating NULL? You're supposed to. >>>>> >>>>> -Ken >>>>> >>>>>> On Apr 6, 2016, at 3:41 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >>>>>> >>>>>> This patch causes a segfault in the event that __wine_main_argv is not the argv that got passed to main. This happened in a program I wrote that acts as a custom wine loader. It creates an argv by using malloc, then passes that to wine_init. >>>>>> >>>>>> Why wouldn’t setprogname(argv[1]) be adequate? >>>>>> >>>>>> ~Theodore >>>>>> >>>>>>> On Feb 19, 2016, at 2:33 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: >>>>>>> >>>>>>> Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> >>>>> >>>> >>> >> >> >

April 26, 2016

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

by Theodore Dubois

I have both a custom wine loader and a hacked version of Wine, so I just reverted the patch. It would be really nice to have this work for when I’m not using a custom loader. Maybe you could check if argv is in the malloc heap? Or maybe I could somehow indicate when calling wine_init that the argv is malloced? ~Theodore > On Apr 26, 2016, at 1:02 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > Sorry it took me so long to respond. > > What this actually does is it changes the ps output so that the wine binary doesn't show up in the command line. Naturally, it relies on the argv block being one huge null-null-terminated list of strings (as most UNIX-like systems do, apparently). If you're not building your argv this way, then yes, wine will crash. Also, if wine's idea of the argv block isn't the one that the OS gave to main(), the ps output won't be affected. > > The code that manipulates the argv block existed in the Linux case. I surmise, then, that we'd have this same problem there. > > I'd kinda like to keep it, but then we'd need some way to detect that the argv we have isn't the block that was passed to main(), or isn't a null-null-terminated string list. (Or, maybe I can use _NSGetArgv() on Mac OS... but then all the other systems we support will still have this problem, and since you've written your own loader, we can't really rely on the order of arguments being "wine" "program" "...".) If you'd like me to just gut that piece of code, I'll be happy to write a patch to do that. > > Chip > > > On Wed, Apr 6, 2016 at 4:03 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > I CC’d him on the original email. > > It would be neat if the wine program name could show up in Activity Monitor on OSX, so I can tell one wine process apart from another. There is a way to do it (http://stackoverflow.com/questions/4217947/setting-process-name-on-mac-os-x…) but it requires undocumented APIs. (Damn.) > > ~Theodore > > > On Apr 6, 2016, at 3:35 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > > > Ah, I see. Yeah, that's weird. Have you tried asking Chip directly? I'm CC'ing him. > > > > -Ken > > > >> On Apr 6, 2016, at 4:53 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > >> > >> Yes, I did. The problem is that the code assumes that argv[0] - argv[1] (= offset) is a meaningful quantity, which it isn’t because each string in the argv array came from strdup. > >> > >> ~Theodore > >> > >>> On Apr 6, 2016, at 2:14 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >>> > >>> Did you allocate one more entry in your argv than is needed for actual arguments and put a terminating NULL? You're supposed to. > >>> > >>> -Ken > >>> > >>>> On Apr 6, 2016, at 3:41 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > >>>> > >>>> This patch causes a segfault in the event that __wine_main_argv is not the argv that got passed to main. This happened in a program I wrote that acts as a custom wine loader. It creates an argv by using malloc, then passes that to wine_init. > >>>> > >>>> Why wouldn’t setprogname(argv[1]) be adequate? > >>>> > >>>> ~Theodore > >>>> > >>>>> On Feb 19, 2016, at 2:33 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > >>>>> > >>>>> Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> > >>> > >> > > > >

April 26, 2016

Re: [PATCH v2] kernel32: Use setprogname(3) to set the program name if available.

by Charles Davis

Sorry it took me so long to respond. What this actually does is it changes the ps output so that the wine binary doesn't show up in the command line. Naturally, it relies on the argv block being one huge null-null-terminated list of strings (as most UNIX-like systems do, apparently). If you're not building your argv this way, then yes, wine will crash. Also, if wine's idea of the argv block isn't the one that the OS gave to main(), the ps output won't be affected. The code that manipulates the argv block existed in the Linux case. I surmise, then, that we'd have this same problem there. I'd kinda like to keep it, but then we'd need some way to detect that the argv we have isn't the block that was passed to main(), or isn't a null-null-terminated string list. (Or, maybe I can use _NSGetArgv() on Mac OS... but then all the other systems we support will still have this problem, and since you've written your own loader, we can't really rely on the order of arguments being "wine" "program" "...".) If you'd like me to just gut that piece of code, I'll be happy to write a patch to do that. Chip On Wed, Apr 6, 2016 at 4:03 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > I CC’d him on the original email. > > It would be neat if the wine program name could show up in Activity > Monitor on OSX, so I can tell one wine process apart from another. There is > a way to do it ( > http://stackoverflow.com/questions/4217947/setting-process-name-on-mac-os-x…) > but it requires undocumented APIs. (Damn.) > > ~Theodore > > > On Apr 6, 2016, at 3:35 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > > > Ah, I see. Yeah, that's weird. Have you tried asking Chip directly? > I'm CC'ing him. > > > > -Ken > > > >> On Apr 6, 2016, at 4:53 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: > >> > >> Yes, I did. The problem is that the code assumes that argv[0] - argv[1] > (= offset) is a meaningful quantity, which it isn’t because each string in > the argv array came from strdup. > >> > >> ~Theodore > >> > >>> On Apr 6, 2016, at 2:14 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > >>> > >>> Did you allocate one more entry in your argv than is needed for actual > arguments and put a terminating NULL? You're supposed to. > >>> > >>> -Ken > >>> > >>>> On Apr 6, 2016, at 3:41 PM, Theodore Dubois <tblodt(a)icloud.com> > wrote: > >>>> > >>>> This patch causes a segfault in the event that __wine_main_argv is > not the argv that got passed to main. This happened in a program I wrote > that acts as a custom wine loader. It creates an argv by using malloc, then > passes that to wine_init. > >>>> > >>>> Why wouldn’t setprogname(argv[1]) be adequate? > >>>> > >>>> ~Theodore > >>>> > >>>>> On Feb 19, 2016, at 2:33 PM, Charles Davis <cdavis5x(a)gmail.com> > wrote: > >>>>> > >>>>> Signed-off-by: Charles Davis <cdavis5x(a)gmail.com> > >>> > >> > > > >

April 26, 2016

Re: kernel32/tests: Add initial tests for GetConsoleFontInfo (v3)

by Sebastian Lackner

I am aware that this patch is already committed, but since you are probably still working on the follow-up patches, here some remarks: On 26.04.2016 14:06, Hugh McMaster wrote: > + GetCurrentConsoleFont(std_output, FALSE, &cfi[0]); > + index = cfi[0].nFont; > + orig_font = GetConsoleFontSize(std_output, index); > + You might want to do a memset here. Currently some of the tests pass, although Wine has no implementation yet. > + SetLastError(0xdeadbeef); > + ret = pGetConsoleFontInfo(std_output, FALSE, num_fonts, cfi); > + todo_wine ok(ret, "got %d, expected non-zero\n", ret); > + todo_wine ok(GetLastError() == 0xdeadbeef, "got %u, expected 0xdeadbeef\n", GetLastError()); > + > + ok(cfi[index].dwFontSize.X == win_width, "got %d, expected %d\n", cfi[index].dwFontSize.X, win_width); > + ok(cfi[index].dwFontSize.Y == win_height, "got %d, expected %d\n", cfi[index].dwFontSize.Y, win_height); Could you add an additional test that (cfi[i].nFont == i) holds? If GetConsoleFontInfo would return elements in arbitrary order, the code above would not work. > + > + for (i = 0; i < num_fonts; i++) > + { > + tmp_font = GetConsoleFontSize(std_output, cfi[i].nFont); > + tmp_w = (double)orig_font.X / tmp_font.X * win_width; > + tmp_h = (double)orig_font.Y / tmp_font.Y * win_height; > + ok(cfi[i].dwFontSize.X == tmp_w, "got %d, expected %d\n", cfi[i].dwFontSize.X, tmp_w); > + ok(cfi[i].dwFontSize.Y == tmp_h, "got %d, expected %d\n", cfi[i].dwFontSize.Y, tmp_h); > + } It wouldn't hurt to HeapFree() cfi here. > +} > + > START_TEST(console) > { > static const char font_name[] = "Lucida Console"; > @@ -2925,4 +2998,5 @@ START_TEST(console) > test_GetCurrentConsoleFont(hConOut); > test_GetConsoleFontSize(hConOut); > test_GetLargestConsoleWindowSize(hConOut); > + test_GetConsoleFontInfo(hConOut); > } >

April 26, 2016

Re: The future of the native theming support

by Joel Holdsworth

> There also were some questions about integrating new themes to the > existing system. If it matters, I found a way to make it transparently > for the end users. A new "GTK+" or even "Mac" theme can live together > with old MSSTYLES themes without need of switching any "theme drivers" > as it was said in my GSoC proposal. wine-staging has an optional feature to do this with Gtk [1]. The results are so-so. The issue is that typically uxtheme and an external toolkit have very different ways of describing layout and therefore the there is no 1:1 mapping between any arbitrary Gtk theme and uxtheme. The result is that certain themes look much more glitchy than others - but it will look extremely crappy if the integration is less than pixel perfect, which is going to be extremely hard without lots of fragile heuristics, or manual artistic tweaks. I recommend having a conversation with the author of those wine-staging patches, so you can find out how things are going with that. He's got some things working, but still lots of glitches. These glitches may be fixable - but I'm fearful that some problems may come down to a design conflict between windows and Gtk+. If you want to spend time on this, I personally would love to see it come to fruition - but be warned, it's a risky project. In some ways this is analogous to the wine icon set. Ideally it would be nice to pick up icons from the host /usr/share/icons directory. The problem being that in windows, icons are baked into the executable binary. In principle applications could be tricked about the binary resources at runtime, but in practice this is getting into very unpleasant territory where we're in severe danger of causing breakage. So when I updated the icons [2], I chose the Tango icon theme because it represented a modern-looking compromise between the icon styles of most desktop environments. Andrew Eikum's suggestion is rather similar, but for the ux theme. To me that sounds a lot easier to do. Joel [1] https://github.com/wine-compholio/wine-staging/tree/master/patches/uxtheme-… [2] https://airwebreathe.org.uk/doku.php?id=wine_icons

April 26, 2016

Re: [PATCH 2/5] qedit: Stub out AMTimelineObj.

by Andrew Eikum

On Tue, Apr 26, 2016 at 09:06:22AM -0600, Alex Henrie wrote: > 2016-04-26 7:29 GMT-06:00 Andrew Eikum <aeikum(a)codeweavers.com>: > > On Mon, Apr 25, 2016 at 09:09:57PM -0600, Alex Henrie wrote: > >> @@ -129,8 +129,14 @@ static HRESULT WINAPI Timeline_IAMTimeline_CreateEmptyNode(IAMTimeline *iface, I > >> TIMELINE_MAJOR_TYPE type) > >> { > >> TimelineImpl *This = impl_from_IAMTimeline(iface); > >> - FIXME("(%p)->(%p,%04x): not implemented!\n", This, obj, type); > >> - return E_NOTIMPL; > >> + HRESULT hr; > >> + > >> + TRACE("(%p)->(%p,%04x)\n", This, obj, type); > > > > Any reason for the 04 width specifier here and elsewhere? AFAICT > > they're not shorts, but maybe I'm missing something. I'd rather print > > them with "0x%x". > > The 4-digit formatting was arbitrary. However, since the tests show > that the type is not a set of flags, and since it's defined in decimal > in the header file, I think %d makes the most sense. > Either's fine. I tend to use decimal for scalar values and hex for arbitrary values like enums and flags. But that's just bikeshedding at this point. Andrew

April 26, 2016

Re: [PATCH 5/5] qedit: Implement IAMTimelineObj_GetTimelineNoRef and add tests.

by Alex Henrie

2016-04-26 7:33 GMT-06:00 Andrew Eikum <aeikum(a)codeweavers.com>: > On Mon, Apr 25, 2016 at 11:46:09PM -0600, Alex Henrie wrote: >> 2016-04-25 23:10 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> > On 26.04.2016 7:57, Alex Henrie wrote: >> >> 2016-04-25 22:21 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >> >>> On 26.04.2016 6:10, Alex Henrie wrote: >> >>>> static HRESULT WINAPI TimelineObj_GetTimelineNoRef(IAMTimelineObj *iface, IAMTimeline **timeline) >> >>>> { >> >>>> + /* MSDN says that this function is "not supported" */ >> >>>> TimelineObjImpl *This = impl_from_IAMTimelineObj(iface); >> >>>> - FIXME("(%p)->(%p): not implemented!\n", This, timeline); >> >>>> - return E_NOTIMPL; >> >>>> + TRACE("(%p)->(%p)\n", This, timeline); >> >>>> + if (!timeline) return E_POINTER; >> >>>> + return E_NOINTERFACE; >> >>>> } >> >>> >> >>> This looks like a call to QI, according to your tests. >> >> >> >> It looks that way, but which interface would it be querying? The tests >> >> show that an IAMTimelineObj cannot double as an IAMTimeline, nor is >> >> the function supposed to return the IAMTimeline that was used to >> >> create the IAMTimelineObj. My best guess is that Microsoft never >> >> bothered implementing this function properly and so whatever >> >> implementation they have always winds up returning E_NOINTERFACE. >> > >> > Yes, return type is IAMTimeline, so I was suggesting a shortcut doing >> > same thing in one line IAMTimelineObj_QueryInterface(iface, >> > &IID_IAMTimeline, ...). This should cover for setting out pointer to >> > NULL, returning E_NOINTERFACE, and probably handling NULL case too, >> > though it's not a standard QI behavior. None of that is actually >> > important, what you did is fine, take it as a suggestion, or don't. >> >> OK, I see what you mean now, and I'll make that change in version 2 of >> this patchset. >> > > Eh, I'd rather keep it like it was. It's not clear whether it should > be QIing on this same object or on the parent Timeline object, and the > "NoRef" is weird behavior for a QI. Implementing it on top of QI > seems to imply confidence we don't have, and would confuse me if I was > reading this code blind. OK, I've changed it back, except that I'm still setting *timeline = NULL so that the new test passes. -Alex

April 26, 2016

Re: [PATCH 2/5] qedit: Stub out AMTimelineObj.

by Alex Henrie

2016-04-26 7:29 GMT-06:00 Andrew Eikum <aeikum(a)codeweavers.com>: > On Mon, Apr 25, 2016 at 09:09:57PM -0600, Alex Henrie wrote: >> @@ -129,8 +129,14 @@ static HRESULT WINAPI Timeline_IAMTimeline_CreateEmptyNode(IAMTimeline *iface, I >> TIMELINE_MAJOR_TYPE type) >> { >> TimelineImpl *This = impl_from_IAMTimeline(iface); >> - FIXME("(%p)->(%p,%04x): not implemented!\n", This, obj, type); >> - return E_NOTIMPL; >> + HRESULT hr; >> + >> + TRACE("(%p)->(%p,%04x)\n", This, obj, type); > > Any reason for the 04 width specifier here and elsewhere? AFAICT > they're not shorts, but maybe I'm missing something. I'd rather print > them with "0x%x". The 4-digit formatting was arbitrary. However, since the tests show that the type is not a set of flags, and since it's defined in decimal in the header file, I think %d makes the most sense. -Alex

April 26, 2016

Re: [5/5] wininet/tests: Add more tests for INTERNET_INVALID_PORT_NUMBER. (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=22608 Your paranoid android. === w1064 (32 bit http) === http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

April 26, 2016

Re: [4/5] wininet/tests: Add tests for asynchronous InternetReadFile. (v2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=22607 Your paranoid android. === w1064 (32 bit http) === http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

April 26, 2016