Develop Reference

Java Mail SMTP: Removing internal host names and IP addresses from mail message headers

Mail message header is exposing information about hostname and internal IP address(first hop Server). Attacker can easily get information about internal server IP and it is a serious treat.
Message-ID: <5f698024.1c69fb81.621c8.e573SMTPIN_ADDED_BROKEN#mx.google.com>
X-Google-Original-Message-ID: <1634982533.0.1600749603315.JavaMail.production.domain.com>
Received: from <hostname> (unknown [10.11.XXX.XXX]) by devmail01.domain.com (Postfix) with ESMTP id 93DF9C0BD3 for <username.r#gmail.com>; Mon, 21 Sep 2020 21:40:02 -0700 (PDT)
Date: Tue, 22 Sep 2020 10:05:42 +0530 (IST)
From: mailer <mailer#us.abcd-mail.com>
To: username.r#gmail.com
Subject: [502FE0F6] org.apache.http.conn.HttpHostConnectException report for http://localhost:8080
So I added props.put("mail.smtp.localhost", "production.domain.com"); to SMTP configuration and now I see hostname is coming as "production.domain.com"
But still Internal IP is exposed and which is being used for reverse DNS lookup
Received: from production.domain.com (unknown [10.11.XXX.XXX]) by devmail01.domain.com (Postfix) with ESMTP id 2B933C0016 for <username.r#gmail.com>; Mon, 21 Sep 2020 23:57:04 -0700 (PDT)
How do I remove internal IP address for message headers?
Is it possible to prevent reverse DNS lookup?

Play Framework replying not modified when static assets are changed

I moved a Play Framework Project to a new PC and everything is working fine but there is one annoying problem:
All static assets return the 304: Not Modified header even after I edit them. And I think I found the origin of the problem, play framework replies following in curl:
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 527
Content-Type: application/javascript; charset=utf-8
Date: Wed, 14 Jan 2015 17:49:24 GMT
ETag: "4a0670efaaa84f8734d67d4557a7309dfe235301"
Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
The Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT part seems wrong to me.
And also when I edit something, the ETag isn't changing. This is annoying because Chrome doesn't load the changes unless I delete the cache and this makes mobile development nearly impossible.
The same thing also happens when I create a new application. It worked in my old Laptop wich had also Windows 8.

It looks like #3722.
Assets controller sends constant etag if path has a space in the name
Does the path to your workspace or to your assets has a space in it ? If so, remove it and try again.
I hope it helps.

Valid URI results in Content-Length: -1

Since Java 7u21 I stumbled on some strange behavior in a JavaFX applet I made.
On the server side I have a Glassfish 3 server and a mysql database. On the client side I use Jersey to fetch data from the db by sending requests to my Glassfish server. Everything works when I start the program through the JAR file, however when I start it through my JNLP file, I notice some strange behaviour since 7u21. Let me try to show you:
I do a simple request which should give a XML response:
The method (client):
public List<Users> getUsersHierarchyTreeFilteredByUserlevel(int id, int betweenStart, int betweenEnd) throws UniformInterfaceException {
WebResource resource = webResource;
resource = resource.path(java.text.MessageFormat.format("users/{0}/hierarchy", String.valueOf(id))).queryParam("start", "" + String.valueOf(betweenStart)).queryParam("end", "" + String.valueOf(betweenEnd));
System.out.println(resource.getURI());
return resource.accept(javax.ws.rs.core.MediaType.APPLICATION_XML).get(new GenericType<List<Users>>() {});
}
The URI: System.out.println(resource.getURI());
http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
Java console:
network: Cache entry not found [url: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5, version: null]
network: Connecting http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5 with proxy=DIRECT
network: Connecting socket://localhost:8080 with proxy=DIRECT
network: Downloading resource: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
Content-Length: -1
Content-Encoding: null
network: Wrote URL http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5 to File C:\Users\Steven\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\33\d7edc21-130fad10-temp
cache: Adding MemoryCache entry: http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy
java.io.IOException: stream is closed
As you can see I receive a IOException. This seems to happen at resource.accept(...) in the getUsersHierarchyTreeFilteredByUserlevel(...) method. However, when I paste the URI in my browser, it shows the correct XML data? I have no idea why... It works when running the JAR itself or with 7u17.
Any ideas?
Thanks in advance!
Update
*Fetch with wget (64bit)*
D:\>WGET64.EXE -S --http-user=*** --http-passwd=*** "http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5"
--22:06:53-- http://localhost:8080/myWS/webresources/entities.users/users/4/hierarchy?start=5&end=5
=> `hierarchy#start=5&end=5'
Resolving localhost... 127.0.0.1
Connecting to localhost[127.0.0.1]:8080... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
3 Server: GlassFish Server Open Source Edition 3.1.2.2
4 Pragma: No-cache
5 Cache-Control: no-cache
6 Expires: Thu, 01 Jan 1970 01:00:00 CET
7 Content-Type: application/xml
8 Date: Wed, 05 Jun 2013 20:06:53 GMT
9 Connection: close
[ <=> ] 9,610 --.--K/s
22:06:53 (9.16 MB/s) - `hierarchy#start=5&end=5' saved [9610]

It all had to do with the same issues regarding this question:
Authentication required window popping up after 7u21 update
and follow up question:
basic authentication fails with glassfish
Answered by dennis-the-menace which you can find here:
https://stackoverflow.com/a/18362271/1527284

How to properly handle client "Connection: close" request on HTTP file server?

How do I handle properly a client Connection: close request field? As of now if I get this particular field I close the socket and wait for a following request from the client than reply again and start serving the data.
I don't know why my client/server communication is not working as the Apache Server I tested with.
Thanks for any clarifications...
Client/Server comunication:
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
CLIENT:
HEAD /stream.mpeg HTTP/1.0
Host: 127.0.0.1
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.0 200 OK
Date: Wed, 1 Jun 2011 20:05:13 GMT
Server: HTTP Server
Last-Modified: Mon, 06 Aug 2009 01:02:23 GMT
Accept-Ranges: bytes
Connection: Close
Content-Type: audio/mpeg
231489172304981723409817234981234acvass123412323
21312hjdfaoi8w34yorhadl4hi8rali45mhalo3i,wmotw
345fqw354aoicu43yocq2i3hr
Client/ApacheServer Comunication:
CLIENT:
GET /test.mp3 HTTP/1.0
Host: 192.168.1.120
User-Agent: SuperPlayer
Connection: Close
SERVER:
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 19:15:11 GMT
Server: Apache/2.2.16 (Win32)
Last-Modified: Thu, 29 Apr 2010 21:06:34 GMT
ETag: "14000000047049-4f75c8-4856680636a80"
Accept-Ranges: bytes
Content-Length: 5207496
Connection: close
Content-Type: audio/mpeg
...d.....<).0.. ..........<.#.. ( .h.$.J...1...i....A. ......c....a.9..!g.N...A. ........ ....>......|.......8....a......|..|N.............'>........?...C.....#..TJt.n .e...r.iL..#..IH...pR|.

Yes closing the socket is the right action to take. If the client is using this header properly, they are closing the socket on their end once they receive your response.
What I'm noticing here is that your server is not returning a Content-Length header. Even though the client is issuing a HEAD request, based on the W3C proposal (sec. 9.4):
The metainformation contained in the HTTP
headers in response to a HEAD request
SHOULD be identical to the information
sent in response to a GET request.
This method can be used for obtaining
metainformation about the entity
implied by the request without
transferring the entity-body itself.
This method is often used for testing
hypertext links for validity,
accessibility, and recent
modification.
The response to a HEAD request MAY be
cacheable in the sense that the
information contained in the response
MAY be used to update a previously
cached entity from that resource. If
the new field values indicate that the
cached entity differs from the current
entity (as would be indicated by a
change in Content-Length, Content-MD5,
ETag or Last-Modified), then the cache
MUST treat the cache entry as stale.
The key here is to make sure you're telling the client the size of the response without actually sending the data.

The Connection: close header just means that the client is expecting you to close the connection after sending the response. That also absolves you of having to send a Content-Length: header.

May I ask why are you using http 1.0 in the request?
There were no persistent connections in http 1.0, so the server is supposed to terminate the TCP connection after the response, whether you send Connection: close or not.

If you are using HTTP 1.0, there is no persistent connections as alexrs pointed, instead, Connection: keep-alive is being used with HTTP 1.0. On HTTP 1.1, you do not need that because HTTP connections are persistent by default on HTTP 1.1.
8.1.2 Overall Operation
A significant difference between HTTP/1.1 and earlier versions of HTTP
is that persistent connections are the default behavior of any HTTP
connection. That is, unless otherwise indicated, the client SHOULD
assume that the server will maintain a persistent connection, even
after error responses from the server.
Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling takes
place using the Connection header field (section 14.10). Once a close
has been signaled, the client MUST NOT send any more requests on that
connection.
You can take a look at to the HTTP 1.1 RFC;
RFC for HTTP 1.1

Send http request from TCP client in java to Apache

I am trying to send a http request from a tcp client in java. I want to read the http request message from a text file and send the http request through my tcp client.
Http message
GET /index.html HTTP/1.1
Host:http://localhost/xampp/ (is this correct? I want to send request to my localhost)
From:xyz#something.com
Accept:text/html, text/plain
User-Agent:Mozilla/3.5.3
How can i do this?

Host:http://localhost/xampp/ (is this
correct? I want to send request to my
localhost)
I believe you should put at host only "localhost" instead of "http://localhost/xampp/".
I believe you should also modify "GET /index.html HTTP/1.1" to "GET /xampp/index.html HTTP/1.1"
Telnet
But I would first do some debugging via telnet, And if successful I would write code
telnet localhost 80
From wikipedia.com
Below is a sample conversation
between an HTTP client and an HTTP
server running on www.example.com,
port 80.
[edit] Client request
GET /index.html HTTP/1.1
Host: www.example.com
A client request (consisting in this case of the request line and only
one header) is followed by a blank
line, so that the request ends with a
double newline, each in the form of a
carriage return followed by a line
feed. The "Host" header distinguishes
between various DNS names sharing a
single IP address, allowing name-based
virtual hosting. While optional in
HTTP/1.0, it is mandatory in HTTP/1.1.
[edit] Server response
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8