The example doesn't comply with the RFC about icap

[jrossi]

This is a copy of the code from https://code.google.com/p/go-icap/ i never got around to doing anything more with it. I don't think it really has a home and i am willing to transfers go-icap/icap to someone that wants to make it better. Also will accept pull reuqests ;)

:) Thank you

[elico]

OK then. I will fork it later in the coming weeks and then I will pull a request when I will be done with the example fix.

[mkishi]

Hi @elico,

We also found some source codes to fix regarding the "response.go", which does not comply with RFC3507. Please let us know your forked repository, and then we would like to pull a request to it.

[elico]

@mkishi my public fork is at: https://github.com/elico/icap
but I'm not sure what in the response.go you are talking about please be more specific.
Also I tried couple times to fix this library but found it far more simple approach to the subject reducing the usage of ICAP for basic url filtering.
I have seen a nice example of a filtering proxy at:
https://github.com/andybalholm/redwood/
which is only missing tproxy support and I cannot find the sources right now but it's pretty simple to add tproxy support for this.
So in the case you need a filtering proxy for either big or a small environment RedWood is really good.
If I will have enough time I will try to write and example of a url filtering ICAP service that works with my other library: https://github.com/elico/drbl-peer/
If you need examples for tproxy usage in GoLang try to peek at: https://github.com/elico/go-linux-tproxy

[mkishi]

@elico

Thank you for your reply.

my public fork is at: https://github.com/elico/icap
but I'm not sure what in the response.go you are talking about please be more specific.

We have checked the above repository but my facing issue has already been fixed like following !

elico@f370816

"Content-Length" header should not be removed because it is end-to-end header, right ?
Also, it seems that you have fixed other issues. We would like to fork your repository as master one.
And then, will contribute if we find new issues.

[elico]

@mkishi The issue with content length discarding is that the download eventually becomes weird with or without RFC compliance.
Every download that passed thru the ICAP service was eventually without Download Due time\date and for example a 1GB file download was being downloaded for hours and I couldn't know when it would end.

If you want to make my code master feel free.
Do you need me to do something?

[mkishi]

@elico

The issue with content length discarding is that the download eventually becomes weird with or >without RFC compliance.
Every download that passed thru the ICAP service was eventually without Download Due time\date and >for example a 1GB file download was being downloaded for hours and I couldn't know when it would >end.

Exactly.
For your information, according to RFC3507 (http://www.rfc-base.org/txt/rfc-3507.txt),

4.4.2 Encapsulated HTTP Headers
HTTP/1.1 makes a distinction between end-to-end headers and hop-by-
hop headers (see Section 13.5.1 of [4]). End-to-end headers are
meaningful to the ultimate recipient of a message, whereas hop-by-hop
headers are meaningful only for a single transport-layer connection.
Hop-by-hop headers include Connection, Keep-Alive, and so forth. All
end-to-end HTTP headers SHOULD be encapsulated, and all hop-by-hop
headers MUST NOT be encapsulated.

all end-to-end HTTP headers (including "Content-Length") should be passed.

If you want to make my code master feel free.
Do you need me to do something?

We really appreciate your cooperation !
We will open a new issue to your repository if we need your further help again.