header matchers should be case insensitive

[musketyr]

I'm working rest client which is sending headers as Content-type instead of Content-Type causing request body matcher not being matched.

For example having:

post('*') {
    body({ true }, ContentType.APPLICATION_URLENCODED)
    responds().content('OK')
}

should return OK for request containing headers Content-Type: application/x-www-form-urlencoded as well as Content-type: application/x-www-form-urlencoded

[musketyr]

@cjstehno just to be clear, this happens with 1.5.0@safe. I've tried to upgrade to 1.6.0 but I get weird Groovy compilation errors. I'll try to figure more details about the later one.

[musketyr]

see #86 for the problem with 1.6.0@safe JAR blocking my upgrade.

[cjstehno]

Well, it appears that this has been fixed as of 1.6.1 at least... I will publish the fix for the safe jar issue and then you can try the current version. What version are you currently using?

[musketyr]

1.5.0

Dne st 7. 2. 2018 20:42 uživatel Christopher J. Stehno < notifications@github.com> napsal:

Well, it appears that this has been fixed as of 1.6.1 at least... I will publish the fix for the safe jar issue and then you can try the current version. What version are you currently using?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cjstehno/ersatz/issues/85#issuecomment-363886903, or mute the thread https://github.com/notifications/unsubscribe-auth/AAoTteP7ttP3CAXXAcFTe_PzRkX1xVtvks5tSfyigaJpZM4R8-BD .

[musketyr]

I've tried 1.6.1 but the headers problem seems to be still there

[cjstehno]

Odd. Can you provide a full test case that fails. I wrote one based on your example and it appears that the header name matching is not case sensitive in the current code. Maybe I'm misunderstanding the problem.

Knowing the client used might help too and I guess the OS... just in case.

On Thu, Feb 8, 2018, 1:13 AM Vladimir Orany notifications@github.com wrote:

I've tried 1.6.1 but the headers problem seems to be still there

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cjstehno/ersatz/issues/85#issuecomment-364022711, or mute the thread https://github.com/notifications/unsubscribe-auth/AALMKt3XcphtzcvHe4aXRhc_KbmDzrvtks5tSp6agaJpZM4R8-BD .

--

Christopher J Stehno chris.stehno@gmail.com http://stehno.com

[musketyr]

sure, I'll give it a try. this happens with http://restfb.com/documentation/#batch-api

[musketyr]

indeed, I've tried within ErsatzServerSpec do following and it works:

    def 'headers are case insensitive'() {
        setup:
            ersatzServer.expectations {
                post('/foo').body({ true } as Matcher, MULTIPART_FORMDATA)
                         .responds().content('OK').code(200)
            }
            ersatzServer.start()

        when:
            HttpURLConnection connection = new URL("${ersatzServer.httpUrl}/foo").openConnection() as HttpURLConnection
            connection.requestMethod = 'POST'
            connection.setRequestProperty('Content-type', MULTIPART_FORMDATA.value)

        then:
            connection.inputStream.text == "OK"

            connection.responseCode == 200
    }

[musketyr]

I'll try it again

[cjstehno]

Ok, the development branch has the code for the upcoming 1.6.2 release - so far its just the fix for the "safe" jar.

[cjstehno]

Also, on a failure, there should be a detailed description of which matchers failed written out to the logs... perhaps the mismatch is not where you think it is. Just a thought.

[musketyr]

you are right. in my code, I was missing coercion to Matcher so it was triggering method RequestWithContent body(final Object body, ContentType contentType)

maybe it's worth to accept Closure as a parameter for methods as this seems natural in Groovy.

sorry for bothering you and thanks for your help

[cjstehno]

No problem at all. I considered supporting Closure directly before... I may take another look at it.