XmlResponse not writing Content-type header

[Jason Liszka]

When I return an XmlResponse from a DispatchPF function, the response
does not include the Content-type header.

My code looks like:

def dispatch: LiftRules.DispatchPF = {
case req@Req(List("twilio", "call"), "", _) => () =>
callResponse(req)
}

def callResponse(req: Req) = {
val xml = <Response>...</Response>
XmlResponse(xml)
}

Example repro:

scala> val r = XmlResponse(<a/>)
r: net.liftweb.http.XmlResponse =
net.liftweb.http.XmlResponse@5b425a8e

scala> r.toResponse
res6: net.liftweb.http.InMemoryResponse =
InMemoryResponse(<?xml version="1.0" encoding="UTF-8"?>
<a/>
, List(), List(), 200)

$ curl -i 'http://localhost:8080/twilio/call?pin=5156'
HTTP/1.1 200 OK
Expires: Fri, 2 Dec 2011 20:18:54 GMT
Content-Length: 621
Cache-Control: no-cache, private, no-store
Pragma: no-cache
Date: Fri, 2 Dec 2011 20:18:54 GMT
Server: Jetty(6.1.25)

<Response>...</Response>

Whereas JsonResponse, PlainTextResponse etc work fine:

scala> val j = JsonResponse("abc")
j: net.liftweb.http.LiftResponse =
JsonResponse(JsExp("abc"),List(),List(),200)

scala> j.toResponse
res12: net.liftweb.http.BasicResponse = InMemoryResponse("abc",
List((Content-Length,5), (Content-Type,application/json;
charset=utf-8)), List(), 200)

I was able to construct an InMemoryResponse as a workaround. This is
lift-2.8.1-2.4-M5.

Thanks,
Jason

[David Pollak]

Please open a ticket (http://ticket.liftweb.net you must be a watcher of the LiftWeb space on Assembla) referencing this thread and assign it to me.

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Andrew Mullins]

Was a ticket created for this? I have the same issue with Twilio not recognizing my response because the Content-Type header is not set.

curl -XPOST --dump-header - http://localhost:8080/api/twilio

HTTP/1.1 200 OK

Expires: Tue, 31 Jan 2012 04:08:06 GMT

Content-Length: 205

Cache-Control: no-cache, private, no-store

Pragma: no-cache

Date: Tue, 31 Jan 2012 04:08:06 GMT

X-Lift-Version: 2.4

Server: Jetty(7.4.5.v20110725)

[David Pollak]

On Mon, Jan 30, 2012 at 8:22 PM, Andrew Mullins <andrewmu...@gmail.com> wrote:

Was a ticket created for this?

Not that I know of.  PLease open a ticket and assign it to me.

 

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Andrew Mullins]

Done. http://www.assembla.com/spaces/liftweb/tickets/1191

[Josh Backfield]

I stumbled across this same issue; I was digging through the code earlier today and seem to have found the issue.  In the code for S, the method "setHeader" and it's companion "

getResponseHeaders" seems to have a bug whereby if the _responseHeaders.value is either a null or empty box then the new values will not be appended to the list.  

So in XmlResponse, 'S.getResponseHeaders(("Content-Type" -> mime) :: addlHeaders)' does not appear to actually return anything which is why the Content-Type never appears.

-Josh

On Tuesday, January 31, 2012 12:17:10 AM UTC-5, Andrew Mullins wrote:

Done. http://www.assembla.com/spaces/liftweb/tickets/1191

[Antonio Salazar Cardozo]

I believe fixed this issue a while back with https://github.com/lift/framework/pull/1375 .

Thanks,

Antonio

[Antonio Salazar Cardozo]

Related ML thread at https://groups.google.com/forum/#!topic/liftweb/ELwgRJf-yAY/discussion , with a reference to the original issue at https://github.com/lift/framework/issues/1191 , which I'm about to close. Not sure why I didn't attach the pull request to that issue to begin with.

Thanks,

Antonio

[Josh]

The problem is not the def/val difference, it is inside S.getResponseHeaders.  In that method, if you do not have anything inside _responseHeaders.value, then the map that occurs inside .getResponseHeaders is NOT executed.

--

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 

---
You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/tpg6F2Xln24/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Antonio Salazar Cardozo]

Please read the referenced ML thread, where I describe the behavior. _responseHeaders.value is only null in situations where the S scope is not inited. In that situation, _responseHeaders should not be accessed anyway. The issue was that the response objects were accessing it when it should not be accessed, due to the way they were designed.

Please keep in mind that S scope receives a limited initialization even in stateless requests (see S.statelessInit).

Thanks,

Antonio

[Josh]

Apologies for not completely reading that.  I understand your fix now, thanks for the clarification.

[Antonio Salazar Cardozo]

No problem! Notably, the only way to really end up in a situation where you're trying to access an uninited S scope is within a LiftResponse object, and then only if you try to access it as something called from toResponse (because toResponse is invoked as part of the serialization of a response to the socket, which happens after the S scope expires). It may be worth mentioning in documentation for LiftResponse's toResponse that stuff called from here should not rely on a valid S object.

Thanks,

Antonio